 So it's really really really flattered when when a group of Ultra expert project managers and really good friends of mine asked me to help out with this And I got to learn a lot about project management, which I've only been the victim of in the past So so this is this is really fun and conceptually right there are different kinds of projects and and not a There's not one single style of project management that suits every single kind of project and vice versa So this is a this is a take on how like what styles of projects go well with what styles of Project manager, are we ready? Okay, welcome to the dating game. I wish we had that slide with the cheesy music, but I'm jam your host this afternoon today. We will be meeting several projects who need a match of Project management methodology each of our projects will ask three questions of our methodologies So they can get to know each other followed by a lightning round of rapid-fire questions Finally our projects will make a hard decision and choose just one methodology to share their life And now let's meet the methodologies ladies and gentlemen Susie scrum you should take definitely take the clicker Hi, my name is Susie scrum I'm pretty flexible, but I really like you to do things just the way that I ask you to That's what scrums all about for me. I want to make sure that you're doing things in an orderly way Exactly how I want, but I'm totally flexible Yeah, thank you, Susie. Now. Let's meet Christy Kanban like the other side Hi, I'm Christy Kanban and I like to go with the flow. I believe we can all get better with time But we have to start with where we are agree to make changes and everything has to be written on a card Thanks, Christy. Now, let's meet Wanda waterfall Hi, I'm Wanda waterfall. I like to know exactly what I am doing and how long it will take before I do it I don't like surprises like at all and I'm a pretty expensive date You'll have to take a while to get to know me before we can move on to the next phase Thank you Wanda and thank you to all of our lovely methodologies Now let's meet the first project whose heart is up for grabs Larry Longfellow Hi, I'm Larry Longfellow. I'm a serial monogamous. I like cats and black leather vests I'm really looking for that one methodology partner that I can learn with and grow Kind of indefinitely where we're always building and enhancing our relationship Really, there's just no end to how long you know that this relationship could go Thanks, Larry Love the leather now Would you like to ask our methodologies about how they manage the end of their projects? Yes, I would I'm sure you'd like to ask our methodologies about how they end their projects So Wanda waterfall How do you feel about a long-term open-ended relationship? Gotta be honest with you Larry. I just need to know where I stand and when it's over. It's over Okay, then Susie scrum same question Well, I'm fine with long-running relationships and engagements I just need to know where we stand and have a regular check-in Short-term goals give me a really warm fuzzy feeling So it's important that we keep our eye on the ball and go out on regular dates If you don't call me daily, I'm gonna get really really anxious and Okay, thank you, Susie My next question is about continuous improvement Wanda When I've got a good thing going I like to just keep building on it and Improving and increasing that mojo What would you do to spice up a relationship over time and you know keep it moving to the next level? Nothing. I mean really if we haven't planned for it, then I'm not gonna do it If it wasn't in the initial requirements, I'm gonna need you to put that in writing and we're gonna need some form of sign-off Spice it just isn't really something that I like unless of course it was in that recipe I'm more about planning out our relationship early on and sticking exactly to that Hmm, okay, then Christy Kanban, how about you? How do you feel about? Long-term open-ended relationships that we can spice up over time Larry as far as I'm concerned I'm always learning and we can change things every day to make them even better and spicier than the day before If we're going too fast we can slow down and if I'm not giving you all the details you need to make me happy I can change just let me know That actually sounds really nice Christy A follow-up question then How long would it take to get to launch say if we're going out on a date? How long should I give you to get ready? How long is that gonna take? Well like Drupal 8 I'm ready when I'm ready. I mean good things take time If I'm I'm not gonna try to tell you how long it would take me to get ready in advance Unless I have a little bit more detail than a date But I can tell you that when I'm getting ready nothing will be distracting me and when I'm ready. I'm shippable Okay, then Susie Scrum, how about you? Mmm, that depends if it's the first time we go out. I'm not sure yet. How long it'll take me I think I need a few days to find out how fast I can get dolled up before I can leave As we did I think we'll get more accurate because we'll look back on our dates and make some better estimates Thanks Larry and methodologies You certainly given Larry a lot to think about Larry you mull over your methodologies and we'll call you back here later For the lightning round So let's move on to meet our second project quick Rick Tell us a little bit about yourself Rick So my 20 year reunion is coming up and I need a partner fast So my friends don't think I'm a complete utter failure I just want the basics at the beginning but over time I'm gonna need more and more and more and more and my timeline is probably gonna change as will my requirements I'm not all that demanding not really Uh, thanks Rick. I'm sure no one would think you're a complete failure Now would you like to ask your first question of our methodologies? Absolutely. Let's start with some questions about change management Christie convo Let's say I choose a restaurant for us and you make the reservations and get everything ready Then on our way there I changed my mind and decided to go to a different restaurant But we need to get there at the exact same time. How would you handle? For me, I just like to drive until I see something that wets my appetite Whether it's five minutes or five hours away. Who needs reservations? I always like to start with what I know, but I'm open to change Depending on the details We may have to forego the before dinner drinks and appetizers to get you eating at the same time But I'm up for giving it a try Susie scrum, how would you answer that? Well, I like to know what kind of food you're interested in Then we can drive to an area that has those kinds of foods Um, as long as it's no longer than 20 minutes away I hate missing my short term deadlines So we should try and orient our discussion and decision around options that help keep us on schedule and on track Nice, thanks Susie. That was great. Now we'll see how our projects deal with the speed of project delivery Wander waterfall. I like to move really fast I want to take you to meet my parents next week and then we can move in together How would you feel about that? Not exactly what you would call fast moving. I'm much more comfortable taking my time Before getting to that next phase. I like to just take things step by step I would really like to just spend hours upon hours gazing into the stars with you as we plan our future And his screw sheet in detail Okay, then Christy conbond same question I love to move fast speed is what I'm all about So I have no problem De-prioritizing everything else in your life and focusing on that one most important thing to get it done But it's moving in together dependent on meeting your parents I do not like to have too many dependencies In my relationship so that I can focus on one thing at a time But when I can focus on one thing that thing is perfect Okay for my last question, I'd like to know about your estimation processes Wander waterfall. Can you tell me how you would go about planning our first trip together? Well First I would need all the requirements of anything that you could possibly dream of needing for this trip So, you know, whether you are actually going to need these things or not I need you to think about them all Where would you want to go and how long do you want to stay there? And are we talking hostels or five star hotels? Once you've given me all that information I could break it down task by task and give you a detailed estimate estimate for each item of our trip It would really take me quite some time to put this all together though for you But you know, if you don't want to get an estimate at all, just go talk to Christy Sweet burn Well Susie scrum, how about you? Um, well, I'm all about being able to respond to your needs So I like to put a cost on things right before we do them that way I don't spend a lot of time thinking about places. You're not going to take me to Wow Thanks, rick. Those were some interesting questions. Now you cogitate on your choices Or maybe find a good therapist and we'll see you in the next round So last but not least Last but not least Meet our final project Frankie fixed Tell us about yourself Frankie All right. Hi, I'm Frankie. I've been single for a while. Haven't had much luck since the 80s Um, whoa Lots of people think I am difficult and rigid, but my mom says I just like to plan in advance Um, I'm on a fixed budget. So we'll have to adapt our needs to money's limitations I am pretty bad at predicting what I want. Um, even though I spend a lot of time thinking about it Oh, and also I plan to have a million stakeholders. I hope that's okay Um, I just really like input since I have to figure out all the things before I do anything Also full disclosure. I seriously hate it when we change plans. Oh, unless it's me who wants to change plans To add more activities to our date at the same budget, of course So I'll do whatever I want ask a billion people how it sounds take forever to get back to you Not pay enough to cover our costs and then get mad at you if you try to push back on anything in a nutshell Why am I still single? Oh Frank you sound like a catch to me. Would you like to ask our methodologies how they handle documentation? I do love documentation. Yes, uh, susie scrum Uh, I am a pack rat. How will you satisfy my nearly unquenchable need for documentation? Well, I only want to write things down if you're going to read them So it's just a waste of time. We could be spending having other fun What's more fun than documentation? Okay. Well anyway, uh, thanks susie I don't know what's more fun than documentation. But okay, want a waterfall same question So I consider documenting the chronicle of our entire time together to be a high priority How else can we remember the anniversaries the milestones the minutiae of each decision and conversation? You should just see my collection of journals Hmm. Thanks. Wanda Um, next I'd like to ask a question on scope change So Wanda, let's imagine that we've been together for a year now and we've had a couple of features What if a third one came along that we didn't plan? Well, Frankie Frankly, we would have to revisit our entire working relationship. We'd have to cost out this new feature Manage all of the new risks that it poses and determine if it creates any dependencies Then we could decide together if we have the time and the energy available to manage this Of course, we'd have to get all those changes in writing just as before Sensible christie komban. How about you? Well, Frankie, I am pretty flexible as you already know If I have the energy it doesn't really matter what we're doing as long as it's the most important thing to us at the time Uh, we would just need to get started with the details about the new feature that we agree on And then once we agreed I would work on it until it was ready to launch Fair enough. All right, christie. I have a few follow-up questions on budget management As you know, I am on a strict budget. How would you help make sure we don't break the bank on our dates? Well, I can really only focus on one or two things at a time. So that is one way that I can help control costs Uh, I really cannot handle too much at once and I know my limits So if something costs too much You can also adjust the details or priorities to bring the cost down without hurting my feelings If tickets for the concert cost more than you expected, I'm happy to order a salad instead of the lobster without taking it out on you, Frankie Aww Thanks, christie susie scrum same question I like to make concrete plans a little bit in advance. So if you tell me you're going to buy tickets for the concert series I want you to do that Truth bomb I've had a hard time coping when people tell me that we're going to do things that we don't do So if you want me to go to the concert and then the drive through and then change plans at the last minute Like not cool Well, thanks Frankie. I'm gonna let you sit here and reflect on your life while we get ready for the uh lightning round Now that we have stirred up the pot with all these projects and methodologies Let's move on to the lightning round now In this round, we will ask yes or no questions of our methodologies and our projects And to we'll get a better sense of what they have in common and what their differences are We will score the round and that will tell us who matches whom so we have our contestants susie scrum christie kanban And wander waterfall Now our projects Frankie fixed Larry longfellow And quick ricks Methodologies projects I'm going to make a series of statements if the statement applies to you Raise your hand If it does not apply to you you should keep your hand down Are you ready? I can't hear you Do you work with a fixed fee Susie Thank you Do you work best with a fixed capacity team? Can you provide excellent stakeholder visibility of progress on a day-to-day basis? Can you work well with last minute changes? Does your team require specialists? Does your process cost the most? Is your process easy to learn from my team? Well that gave us a lot more to go on Now projects I'm going to have to ask I'm going to ask you who you've chosen. We'll start with you rick I've given it a lot of thought And I picked susie scrum Well that was quick rick I'm not surprised that your need for quick moving relationships with immediate results found a match in susie's iterative and incremental style Okay, next up Frankie fixed who you're going to go home with Frankie Well, I tell you after thinking over for a long long time and considering all the options I'm going to go home with the wonderful wendy waterfall Excellent choice for you Frankie. You like strict parameters and wanders all about detailed plans to fit within them an enlightened choice And last but not least We'll let him think he's got a choice in this Larry long fellow, who do you choose to call your own? Well, uh, you can never be too careful about a choice like this one, but I I think christy konban, and I can go very far together A perfect match you want long-term continuous Improvement and christy is all about taking her time to work on one top priority We will look for you at the ends of the earth larry congratulations Now that our projects have found their best match, let's see if there's anyone in the audience who needs to find a match First up a special. Thank you to Angie rick and larry for their participation Thanks for coming to the session. We'd like to open it up now for Questions about your own projects with our real-life project management experts ashley tevenay shannon vett and jen ceramic I think you should be talking on the microphone I forgot I didn't have a lapel on So we are going to take some time now to answer questions that you may have about Methodologies and how to find the right fit for the type of methodology to its project So please feel free to queue up at the back if you have any questions or on the topic of come to you with the mic Okay, and my jam can come with the mic as well. Thank you very much So does anyone have a question? We can throw out some topics to get you started if you're feeling shy. I have a question What's your question? I'll just read it completely spontaneously off of this list that you gave me Wonderful thank you for your spontaneity We've just heard from three different methodologies Do you feel you stick to just one methodology on most of your projects? Do you have like a personal style? That we like we sort of parodied or do you change methodologies depending on the project at hand And our combinations possible I tend to stick to one mainly because the team Needs continuity on the project and they need to understand how they're going to be working in what processes they're going to be doing That doesn't mean that from project to project. We might do things a little differently But that would take time to train up the team on different processes and different ways of moving forward You want to make sure if you do that that they understand This type of project we're doing Kanban this type of project We're doing scrum this type of project for doing waterfalls type of project We're doing I don't know one of the 20 other things that we have so it's so it's easier to to to To get a team to gel around a particular Way of working over time and not like change every six months or something Exactly or make sure that they're like super honed on all the methodologies You want to use to a point where switching back and forth isn't going to totally throw off your velocity and totally like kill the The gel as you put it of the team. I like the way that that sounds So I just want to add that I have worked on many projects that start agile because we're doing a quick first phase or second phase And then after it becomes evident that it will be a long-term project. It works a little better to do it in Kanban So but those two are the most frequently used for me personally So we don't really use Kanban very much We're more We use agile when we're doing more continuous delivery Projects we have a couple of retainer clients where there's just always work to be done And so we just you know plan out the next thing that we need to be working on and and deliver that in an agile way And then for like bigger project builds or redesigns We do do more of a waterfall process up front that turns into agile later Where we do like to scope everything out get all of you know full wire frames full interaction requirements Get all of our tickets open estimate it that gives a lot of kind of insight Into what the total estimate is going to be for our clients since we we re estimate further into our process and then But then once we start development it is more agile it is trying to Trying to have something that's deliverable, you know early on and after each print not you know just working through the entire project and then delivering And we allow you know there to be some type of report Reprioritization it's not all like set in stone just because it was planned up front. So it's a bit of a combination Hey, so I have a question Do you mixing sometimes These methodologies that you're talking about mean kind of three some between yeah, you know your project and the end the two methodologies, I mean Because I've heard things like a scrimmable foe something between scrim and waterfall. What do you think about? Yeah Yeah What what Wanda described was a little bit what they call scrum fall or Watergile because she there is a lot of advanced planning I think one of the misconceptions of agile is that you don't do any planning It's just like go start do a tweak sprint But there is some planning so that you know approximately how many sprints you need to get to a critical point I would say there are some projects where there are so many different groups working on different pieces that you might have a Like an uber project and then one partner works in an agile fashion and one might work in a con bond fashion And they can work together that way, but it's hard to have a team doing two different processes at once Uh, I've done watergile before It's has its pros and cons But sometimes if you get a customer who just really really wants to plan everything up front and they won't do it any other way And if it's between you losing the bid Or doing a whole ton of upfront planning Sometimes you you just take the hit right and you do that planning, but then you try and say We're going to segment this this way in these sprints and by the way we might change Depending on how this goes and there's usually Throughout each sprint a renegotiation that just naturally happens through prioritization With the customer and things get added things get removed. So it is kind of Waterfall slash agile approach and I've had success doing that But it is hard because you're sitting in between two methodologies And your customer couldn't care. He just wants to know that the stuff he really wants is getting in So it's it's a challenge to make that work But you can if you're really like have a good communication with your customer and can Negotiate those changes. It can be very stressful for the project manager. I think They're all stressful for the project manager. Let's face it Hi, I'm Joseph. Thanks for the entertaining introduction It's really fun At the Macy we started using scrum a bit more than a year ago And it was kind of interesting to find out how how to fit it into an Existing process that we couldn't define before And one of the challenges that we were discussing is how can we fit A methodology like scrum onto having multiple customers different loads of projects So we ended up now having stable teams that it feels really good But we are kind of unsure how to progress with the maintenance that we're doing besides An idea is Kanban, but I would like to see What what do you think about do you have like a separate maintenance team? How does it work for you? At aquia we have we have a continuous delivery team But they they cover things just more for a period after launch. They're not sort of designed to be involved for years Um, I have worked in a in a sort of a potted company before where the project team stays together And what we did was we alternated So so the each pod would have a project or maybe two if they were small and they would Rotate through doing maintenance So, you know, they did a couple of projects in a row and then they might do six months where that team is taking Kanban tickets for maintenance across many sites and then in six months they'd work on another project for a long time again We I've been I've been in an agency We've done that two different ways the way that you're describing where it's like rotating through tickets and also kind of planning maintenance around free time So whoever's on the bench You're going to do some maintenance tickets and I can't say that we did that kanban, but in hide site We probably should have you know, like what's the hottest most prioritized thing Uh, it just kind of ended up being that way. It just wasn't planned. This is in my green days Um, but yeah, we did it either that way or are we just benched people were doing maintenance We are in the process of setting up a separate support team And I'm going to let them decide how they want to run their own team But what we're what we've mostly been doing now and what we'll likely continue to do at least to some extent is to Kind of have an agile Yeah, way of going about it where we would plan just like a monthly sprint for each of those kind of maintenance clients Um, you know working through their backlog planning out that sprint and leaving a little room for anything urgent that Comes up in the month We said this on a different session But having a planned sprint for technical debt was really helpful for me to make sure that we were constantly Taking care of that between your features tech that just plan it in advance that way that gets done Sometimes do every three sprints or every two sprints. There's a you know technical debt sprint or just a fix it sprint That's a good way to do it Um, hi. Yeah, I I want to ask the opposite of that question perhaps I'm interested in Evolving and we're teaching our clients to work with experiments all the time optimization and experimentation um, but i'm still exploring the way in which it fits into the You know, we we do any for the scrum, but Yes experiments are a kind of the things that come before your scrum. You don't quite know what's there So i'm interested if you hadn't any practice in exploring adapting your processes to experimentation based theory And eventually you get something that evolves into the thing you want to build Are you talking about proofs of concept kind of experimentation or process experimentation or sort of ab testing Some new ideas slowing them in a few places establishing your metrics working out. Ah, right We if we tried this approach, we're getting more better results and therefore let's build that developing a product rather than developing a process Yes, yeah the product development ab testing and that sort of thing going ahead Personally, I would say that kanban works really well with that because you're not you're not taking on too huge chunks of work Like a whole team's two weeks work Before you get a result and can assess whether that worked or not It's really just you know a person working on they set their own capacity So if i'm a developer i can say i can only do six story points a week That's it and i don't i'm not i'm not pressured to be able to plan more ahead than that So if something goes wrong It doesn't it doesn't kill the whole sprint it just kills one person's activities for the week And so it doesn't cause as much unpredictability So for me that would be the way I would do it if I had a lot of proofs of concept unproven things that I was trying to build I mean generally if we're doing any type of ab testing or Yeah, we don't Typically do proof of concept where there's any type of build involved We would do that more in at the ux level and take wires get some user testing out there and See how people are responding. Are they understanding where they need to be clicking and how they're supposed to be interacting with whatever you've designed And then read you know adjust the wires and rework that retest it make sure that that's Getting a better response and then move into planning out and building it We have done some ab testing though with like More on sites where it was kind of like there's an existing landing page. Let's work with different placement of I don't know if like blocks of calls to action of things like that But not anything where there's like a full-on prototype that need to be done to test things Um, I agree with christy. No, I'm just kidding Yeah, I think kanban is a really good method for um Getting short term feedback and making a fast decision about it. I think you could also use agile If you did a round like if you had a sprint that was ab testing and then a sprint that was Doing stuff based on those tests That's one way that you could use that methodology with that format, but I like her way better I think it's easier if you just say, you know, get the information Make a card if it's, you know, the most important thing it gets done Otherwise it shovels in the deck until it's it's time Um, I'm in agreement with that Yeah, hi, I'm batty Um from iceland I wanted to ask you about public offerings. How you um, because this governmental projects You basically get a request for proposal. You can ask a couple of questions. You don't know anything more than that You have to put a price on it and if you win it, you're a little bit stuck with that Uh, so what is, you know, have you experienced with that and what is your experience of what mythology is then best In these type of projects as we don't have the Opportunity then to start like negotiating with the people in on this one year period I'll say that um Governments are probably very different around the world. I live in the united states where the government is extremely slow moving and incredibly bureaucratic Maybe it's everybody everybody else's too. Maybe they're not that different around the world France is not like that at all So in the united states, there's actually a an agile initiative happening in the u.s. Government that that a lot of People like us who've been serving the u.s. Government have started coming in and saying hey You know this punch list stuff doesn't work with the way that it works best and you guys want to save money And we're u.s. Citizens paying taxes. We don't want to spend your money unwisely anymore than you do so, um It's got some traction and one of the areas where it really breaks down is in procurement because U.s. Government contracts are usually very Specific deliverables based and they're not they're not used to working in a contractual process that allows any change at all So it's pretty heavy So What we tend to do is just is just educate them about agile So they understand you're going to get more the this way that you That you're making the decision each moment about what's most important while things change Then you will if you if you do it in a fixed bid We still end up doing that but some of our larger government contracts are actually Kanban because they're long term so So it's a little bit It's definitely tricky and I think it's it's a lot of education the the u.s. Government Anyway, the u.s. One is still very entrenched in waterfall and they're slowly coming out of it The uk government has been a real leader in action around changing how that works They had a code, you know coded deliver at first talk about it later policies starting a few years ago With a number of other changes around their governments a preference for smaller um Projects under a hundred million pounds and to really level the play of playing field for open source and for local sms but the idea that like Throw literally throw up a website online and then talk about what's wrong with it is is, you know Really really radical for governments and it's been it's been showing great results That you know look at gov. You Dove yeah gov.uk and the stuff that's been going in the local councils there with Drupal too. It's been really it's It's really really different Jeff So something's been eating away at me for years. I wonder if anyone else thinks about this. Um Hi, my name is Jeff. Hi This is my confession But but we're you know agile was developed as a way to Incrementally develop software that was generally speaking more like a custom type solution, right and we've all come to adapt it to The purpose of building websites has it ever occurred to you though that maybe building websites and agile don't go together in the sense that Typically these days we're all replacing an existing website like it's not it's very infrequent that we come across something It isn't already out there So there's a certain amount of it that's fixed whether you like it or not Then you've got these public users you can't correct them or change them And then you've got the normal client stuff. So a website in its Nature at times isn't as easy to adapt to an agile methodology by virtue of what has to get done So just wondering if you guys Struggle with that and does is that what leads you to? Water water Gile, right? Um, I struggle with that sometimes I feel like A lot of customers that I have worked with are expecting some fixed properties Um, namely budget schedule and scope But they want you to be flexible and deliver fast and do everything they went Yeah, they want the best of both So it's hard to get the customer to adapt They're thinking to Okay, maybe my budget's going to expand or maybe my scope is going to decrease or maybe probably both Um, so that can be hard And at those times I'm like, yes, this isn't adapted But it's not the methodology that I have the problem with it's the customer Like they need education they need to understand there is a triangle And you cannot have fixed everything you just can't and that's how I manage that problem When I have that customer that wants fixed everything I draw them a little picture and we sit down and we talk about it And I say what do you care the most about do you care about your budget? And you like literally have no more money and that's it or is it your schedule you have an event And it needs to be launched in this timeframe beforehand Or is it your scope if you don't have this feature it has no value So these are that's how I explain it to them to kind of Find where the priority is in that triangle and then I say, okay This is your priority then or this and this So which of these do you feel comfortable being flexible on and if they say, you know, None of those three they can be flexible on Then I say, okay, this is let's talk risk and then we risk manage and we say What if this happens? What if this happens? How are you going to manage that problem and then that further develops the discussion around Where really is the priority that cannot be shifted? And I just iterate through that discussion until we find it So do you know the old the carpenters joke when you need work on your house and the carpenter comes in He says I can do it. No problem. I can do it fast and cheap and good pick two So we got to make that the project manager show the project manager's version is that good is consistent quality never changes You don't drop quality. You can change what you fix price fix quality, but you adjust scope So it's not really a joke. Sorry. It's not funny I've ruined it Yeah, that's a downer Can I just ask one question whilst I grab the microphone? Ashley, what did you do to deserve to become The water wonder water? There must have been an awful shockingly. I volunteered for this role No, really we chose them and I was like, I'll be a waterfall, but it was great. Thank you very much Yeah, so Going back to that question, uh, that is partially why we Have the process that we do around projects that are kind of redesigns or rebuilds or you know migrations to a new version of Drupal So part of it is we communicate From, you know, the bid we explain like this is our process. This is what we're going to do We don't know your project very well yet. So, you know, as we gather these requirements, we are going to You know, define what we're building together and we're going to re estimate it And so we make it very clear that there's different steps in our process and the original estimate is Like it's a guess based on whatever we have from the rfp from the meetings that we've had And that once we get more information from our wires from interaction requirements and things like that We will reassess we will re estimate and we will give them a full list of These are all the tickets that we see. This is you know, the kind of the full scope as defined together throughout You know this definition process And here's the estimates and then it becomes a question of choice for the client You know, if they want all of those things that are in scope Well, then we're going to have, you know, maybe maybe it's over budget. It doesn't always happen But if it is then they're going to have to either maybe they can tap into other budgets that they have internally that happens sometimes or Maybe they have an internal team that can help, you know, offload some of the the development effort You know, we've done that before as well or You know, maybe they don't need everything that's in the scope right now and then we can Talk about phasing things out and you know taking some of those tickets and some of that defined work And that just kind of becomes your phase two for next year's budget Yeah, so I think that that is kind of why we've adopted our process the way we have So I heard that question a little differently. Maybe you can reflect whether I heard it the way in another way that you meant it I think agile implies that everything is equally changeable and flexible and You know, hey, we make up this foundation now and we'll work for six months And then hey, we'll just switch the whole you know, dribble version that we're on or something So how we manage that is really In communication So when we're making a decision when we're sprint planning or you know Some of the core decisions that are made when we first do the initial planning for a project and we document decisions So, you know, here's the decision that has come up. Here's the background information about it Here's the pros and cons of going this one way or another. Here's our recommendation And then what's your decision so that not only does that person really understand what is at stake and making that decision Like you can't change this later or it will be incredibly expensive if you, you know Go for a totally different theme grid six months from now You have now so they really understand the the the stake in their in their decision And we document it so that, you know, web web teams change and managers change And so they can bring at least those key decisions along with the project without having to overly document it So that they know, oh, you know, we already went down that road and we discussed it And we decided this because there was a real reason for it And then and then they don't have to keep wondering whether that was the right thing to do They can understand like at some point. This was the right decision That's also protective of the developer because, you know, sometimes when a decision gets made six months from now It's hard to explain why you went one way if you didn't document it Like, oh, you know, well, you guys knew we wanted a calendar and this wouldn't work on the platform you used So sometimes clients can forget that, you know, you didn't know that six months ago And you made your decision based on not knowing that so so documentation of those decisions is really key Hi, I'm Paul and I just wanted to add up on the government Issues some thing We have been working on a fair amount of projects for the european commission and mostly in the research department and like the Requirements for the websites. They are only one line in the whole paragraph of the call and what we do is We create a basic Proposal to what what we think they need at least and then we add all the other stuff that would be like fancy as kind of modules and declare what kind of What budget we would need to add that and that Is one way of like getting more money when the project actually starts if you like win the call So just wanted to add that one almost like like a little Grab bag of stuff that yes. Yeah, exactly. So like that Yeah, yeah add-ons. Yeah, because they often they do not even know what they want So because they are from the research a dj environment or something And they just want a project website, which documents all stuff and later on they decide Oh, we would have like like a database of like methods or something But you're filling in those details for them like based on what comes out of the box with whatever Starting with like waterfall because we are like creating the requirements ourselves for the client We describe what we could do and then later on we are actually more approach very good idea I like that idea so when I was Still consulting one of the problems we ran into All the time were projects that came with part of the projects pre-made Not necessarily in a way that would fit well. Usually it was you know a design was made Maybe it was photoshop. Maybe it was actually done correctly and then they hired it as a company to implement it And then okay, this is the design. This is what we want to implement it What do you mean? You don't know if you can do all of it How do you deal with that kind of case where a project is like brought to you halfway through one of these processes and That's not actually going to work going forward I like to use what I call annotated wireframes So for me, my favorite thing is when I can sit down with a technical person and a set of wireframes and just You know, if we've already proposed something and put a price tag on it Without seeing the wireframes, which often happens like hey, give us a price tag. Here's the big wireframe After the fact So so just going through those very carefully and and annotated them saying, okay, this is going to be a view This is a block with this functionality This I don't quite know how we're going to do that yet So they can see, you know, what is going to be troublesome And then also, um, that's a good way to phase things in So if you're looking at an mvp and you can and but you have a full set of wireframes You can start to sort of like Light gray out the things you're going to do, you know After the first phase and then more darker gray the things that are like, oh, this is phase two This is phase three and like the stuff that's black is like or maybe we're never going to do that We'll see if it's complicated So that that for me is my favorite thing if if a developer is willing to sit down and has the time to Sit down with me like that. It makes me feel a lot more secure You mean someone from your team? Yeah And I would say that but pay me to do it You know have like a discovery phase that's built into the offer Yeah, that's what I was going to say We would include some form of discovery even if they're coming to us with wires and even with comps Inevitably, they're not going to be complete Because if it wasn't done by a company that builds websites, they're going to have forgotten some pages or glossed over some things So we'd at least include some time for discovery for review of these for adding and anything that's missing And sometimes as we start to do that well that budget Ends up increasing because we are missing more than we thought or because their wireframe stink Um, but then that's just a discussion that you have with the client At least they're already kind of prepped for that in the bid then something that we're going to need to do at least a bit of Quick word of warning Now a warning um if you If you get one of those projects really good idea to have two things One a handoff discussion with the former Shop or you know agency or whoever it is that was working on that project Do a handoff you're going to learn so much from that group like don't talk to this lady. She's insane And you know this one will say yes now, but then say no 10 minutes later So prepare for like two hours of discussion about how this search box will work Um, they'll give you a lot of information about the customer And probably tons of reasons why that failed which brings me to number two Is have a retrospective with the customer Why did this fail the first time? And that's going to tell you tons about how to avoid those same problems and issues And if those wireframes for example didn't work out for one reason or another you're going to know During that discussion. So whenever you're taking on a project like that to me it usually smacks of rescue Um, and that's tough. See in our case. It was rarely rescue. It was usually You know, we hired a design firm to design it and now we need code monkeys to actually make it happen and That that was an awful lot of the business we had I'm picturing you doing that When I don't have a microphone in my hand, I will We'll do that tonight over drinks. That's right. Yeah, but I actually, you know, Jen there christy Do what you're saying. Um, yeah, I got very good at reverse engineering Uh wireframes and uh photoshop comps into Drupal How much of that do you share with the client though in terms of You know here here's why this piece here is going to be crazy hard It's because of xyz and the way Drupal works or in the way content management systems work How transparent are you about those details with a customer who usually photoshop comps are the extent of their Comprehension of content I tend to err on the side of client education So i'm you know people have to make me warn me not to be so transparent because i'm just like learn this You'll bet you'll work better together next week. So for me um Teaching them how to do things and especially with design people like visual designers Their job is not to just design something cool. Their job is to design something cool. That's buildable Please tell the designers. I used to work with this. Yeah, so so this is the same thing I you know the analogies with architects they they can't just put any design They're required by law and why they have to take so many certifications is because they have to build something That's actually buildable and it will stand they find a thing that says this building will stand at the On a set of plans visual designers. I think we should hold them to the same standard um, and that requires That requires them to learn something about the technology that they're designing for before they start designing for it So I really encourage if you're in early early conversations with a client and they haven't hired a firm But they've told either they intend to Try to get in there and teach them about Drupal or send them to aqua academy If you want to you can free courses and you can have them to learn about Drupal there And and ideally, you know train some of the content producers if you're working on a long project It's worth the time up front to just throw Drupal eight up there and have the the designers start to play with it And see what it does and get a sense of how it actually works because their designs are going to be better As a result What about the working processes where you you throw up a Drupal installation and use it as your living wireframe? And you just build the thing, you know together Does that make it the most realistic? I mean, that's really good if if your visual designer is willing to adjust their process But that's not usually the process that visual designers use Drupal eight really, you know Drupal in general and Drupal eight and lightning which aqua has been developing provides a really awesome Forum for the kind of rapid prototype concept where instead of having a very like want a waterfall-ish conversation about every feature and function You can just throw up a module that you would like to use for whatever that is like a calendar or a forum or whatever it is And just say what do we urgently need to change about this in order to be have it be acceptable or lovable or whatever? And and and just curtail the whole you know if they start going off beam and saying like going way into custom stuff You can say okay. Gotcha. You need these 10 other calendar features Let's hold off on those because it's going to cost you these other critical pieces We need to get done. Let's get those done first and where we visit the calendar If it is again the most important thing and make those other changes I like that approach and i've done that approach and it depends on your customer Whether or not that will work because if your customer Is of the it must be pretty before you show it to me Otherwise they're going to be like but this is supposed to be red and it's not red and you're like go away die um If your customer is like that then that approach I would say be careful because they might just Focus on every little detail and then you will want to strangle them Well, that's what about balsamic markup About mock-ups before that's the point of those wireframes the annotated wireframes is that There's no design and you say to the customer There's not supposed to be any design here if they come at you with a design You're kind of like all right. Let's talk about your design And they'll want to focus on a lot of detail sometimes But I like the idea of saying like here's how you would work through that process according to Drupal and If you can prototype that's better, but I haven't had a lot of customers willing to do that They all kind of get into the nitty gritty. Maybe I just said bad customers Okay, so we're pretty much out of time does anyone else have a last burning question anybody anybody Bueller Can you just tell us on the other side? How do you motivate your team? When the burn down is not going the way to go Do you have any tricks like in the sprint? The line is not going down. It's actually going this way Do you have any very small short trick that you use to motivate your team? Well, there's always ice cream No, but You could talk to the customer about prioritizing some quick wins What are some small but necessary features that you can build in a day or two that will help your point scale down And look a bit better Otherwise, I would say encourage your team and say I know we're behind. You're doing a good job No one here is clairvoyant And this is the product is good the customer's happy sure a burn down chart isn't perfect, but hey Mike's got an idea And I will say again before I'll sound like a broken record, but I get the Kanban idea of finishing So get everyone to concentrate on one card and finish it And then you'll get down I would say in terms of motivating people If if you're behind And you're an agile then the best thing to do to motivate the team is actually once the painful sprint is done Re-look at in retrospective how they're estimating Are you feeling pressure to take on more than you can really do in a sprint? Because sometimes that's really what it is And the other thing is just help have the team help each other If if there's somebody's cracking their head against something just be like There's no there's no attachment to who finishes a ticket if you took it just pass it to somebody else and see If they can make some progress Um So Susie and Christy may not like this very much, but I sometimes take liberties with sprints and just take stuff out of it Because if you're not gonna finish it why make everybody feel bad about that so Yeah, it's pretty most of our cut No, I mean they all have access to our JIRA They can look at the sprint at any time But most of them are not following this sprint so closely where they're like every single ticket It needs to be finished at the at the exact end of this sprint. That's generally not the type of client that we have Yeah, and for every task that's you know misestimated Under as to or you know, mis underestimated, right? You know for everyone that is taking too long Usually run into a couple that are quicker than you expected I loved being on an agile team where we had a really incredible set of specialists who like So they would um, you know, we'd have like a we'd have like a javascript ticket And the hardcore back end guys would be like, oh god, that's like eight 12 points Right in the planning poker and the front end guys are like Half a point one point So that sometimes things fall through the cracks, right? If like somebody's not there on the planning day So there's I I found they were bad sprints and good sprints that like in the end it It got pretty even Thank you so much for teaching me so much about uh project management today and letting me be part of this Thank you for coming everyone a big round of applause, please for our lovely methodologies