 Okay, I think we should start all right Okay, how many Try to figure out who's here How many stakeholder Product owner type people are in the room web producer types kind of like client types What about project managers? Developers Okay, cool. All right How many people are familiar with the terms agile and waterfall it's kind of like everybody, right? Like I should have done this session like two years ago. Now. It's kind of like over great Okay, how many people in the room are considering going for an agile methodology in an upcoming project or something How many people are kind of unsure of that decision or have Entered into that decision. We're gonna go agile and I feel kind of uneasy about it Not really sure how it's gonna go How many people in the room are just like yeah, absolutely agile all the way every day Okay, what else does it want to how many people have had an agile project go great wonderfully like everybody, right? What about horribly? Nobody's immune, right? It can go anything yet can go great or terrible. How many agile experts are in the room? Right, okay humble humble man, but good go easy on me This is supposed to be like a ten thousand foot view, you know of a situation. It's kind of been happening where consultancies are taking on agile methodologies and Kind of to some extent forcing it upon the clients or also more clients are getting You know, they're getting trained at their university in some form or another And they're coming to consultancies saying we want to go agile, which is like a dream for consultancies Okay, so let's see Okay, so the for the purposes of this talk I'm going to Define agile as an inner iterative development process in which getting something like what we wanted When we want it and for the available resources is kind of how we're gonna define that and waterfall is a sequential development Process where we try to get exactly what we wanted For what we wanted to pay for it when we wanted to get it I'm with the last call media and We're a Drupal focused web development shop. We've been doing Drupal for a long time We've done a lot of things Got a lot of battle scars Right now we just do national brands to local retail stores start to finish graphic design social media content strategy Copywriting like we we've got a bunch of people do a bunch of stuff Really our big strength and all that the thing that we're really proud of and we're always trying to push forward is enterprise development workflow and best practices around all that we really get into the Deployments I love deployments and I love testing the deployment just everything tested helps you sleep at night because otherwise That's a major risk. If something's gonna blow up on production It's gonna come down to me to deal with it and that makes me lose sleep That's what we like to do. I'm Kelly Albrecht. I'm the CEO of last call media that just means I've been there the longest and I've been doing Drupal since 2007 pretty much once I figured out Views and cck. It's just like all right. This is this makes sense. I dropped June will like immediately I'm the lead organizer and presenter at the yearly Drupal camp that we do in Massachusetts in the United States and So I have a lot of respect for what goes on at these conferences because I can just imagine that effort that it takes to do a Camp and then multiply it by 20 and that's what they pull off here And they do an amazing job. I'm really honored to be up here today as well So I presented those camps and now I'm at this conference Okay That's a picture of a young me right It's almost a former life at this point I really enjoyed being able to do that. I don't know if I still can but I put this up here because I do like going fast. I do like taking risks I like the excitement, but you can't tell from the picture because it's kind of crazy But I like calculated risks I like the what I loved about this is you can start building small jump jumps and kind of learn the physics of it and get bigger and bigger and bigger and Small steps, you know one small step at a time and you're doing something super fun But in building those those jumps you're kind of straining the order you're you're like pushing pushing the limit and You're kind of right there in the chaos, you know if you fall that's kind of chaotic like the The bike goes everywhere dirt goes everywhere, but really there's some order behind that too Gravity right it's like a rule. It's a law. It's always pulling everything down So you kind of get in the middle of all that thing and you can kind of see when you're walking that line it's really fun, it's a really fun place to be and It's very can be very introspective. You can kind of see where things can cross over from order into chaos And you can also see start to see where things cross over from chaos in the order This is also a young picture of me, right? I stopped combing my hair for him for about six months I had a head full of chaos Right, but then this really cool thing started happening, you know, I was young studying politics And I was just kind of experimenting and stuff and I just thought this would be great This really cool thing started happening where like the strands like ordered themselves And it was it was just a really neat thing to have happen. I don't know. I think the dread think dreadlocks are really cool Everybody may not agree, but Order does kind of find its way into things. I've grown up a bit since then I've cut my hair I Become absorbed in my family and my work I still enjoy things like roller coasters and the beach and hiking and rock climbing. Here's a cool picture of me On the edge of a cliff, you know, kind of just having some fun and excitement taking some risks doing a little bit more And I'm not introducing myself in this way because I want you to think that I'm cool Maybe just a little bit, but you know, that can't really be helped, right? But I want you to know that not only who's up here today because you have to introduce introduce yourself somehow But I want you know that I'm not averse to risk. I'm not obsessive about planning I'm not like, you know, I don't over plan. I have trouble planning and just a general way, you know We all struggle with some things but So that's a struggle I think for everybody right with it, you know, let's let's plan Let's get the specs done So I don't have a bias towards over preparedness or preparedness. I don't make lists I don't make lists of the lists I need to make and I'm not saying that's a bad thing The people that do that are amazing and we need them. We need them. We need them to write the specs and everything But I think at each one of our cores There's a little bit of that dreadlock Kelly that we saw a few slides ago like let's just go Let's it's gonna be fine. It's the order is gonna happen, you know It feels like chaos right now, but we're just gonna get to work and we're just gonna get it done and something great is gonna happen So any order that you see here for me personally and probably for a lot of us kind of fell into place as We were growing between the order and the chaos in our lives. It kind of a lot of times It just falls into place. It's really hard to force it in there So a lot of it happens by happenstance basically so At the time of this picture I still dreadlock Kelly a little bit, but I'd started to become eyeglasses Kelly, right? so in this picture I've got on this shirt of this computer company that I started a long time ago and Computer repair shop and I just kind of went at it. This is the This is the empty shell of a space that I rented and I kind of knew where I wanted to go I kind of knew what the end deliverable was going to be Bought some flooring over there oh And I knew where I wanted to go, but I'd limited resources also and so I started building it just went at it Added things if you know if I needed to change the requirement along the way. I just did so I just kept chipping away at it Here's some more pictures. You know the electrical got put in we got in some lights up there I've got an air compressor I borrowed from my dad Just kind of you know I didn't really have any specs and a lot of times when I think back to this time in my life I think man if I had spec to this whole thing out if I had planned all the pieces that it was going to take to get This thing off the ground. I wouldn't done it Sometimes you only can get things done by just getting to it and getting to work and you know change being allowed to change the requirements I've got some paint up on the walls there some some Retail grid wall, which is surprisingly hard to find You know buying buying things to sell things is not like a typical thing that people do And so here it is. Here's my launch ready product product It launched like this about when I wanted it to launch There's still some things about it that I just had to live with Like I never really liked the this paint color. I think you can agree right? It's like Right, it's like it's like a brick. I don't know. I don't know what I was thinking But I wasn't going to buy a new paint and I wasn't going to paint it again. Just said oh, well, all right This is this iteration the store doesn't look anything like this now. We've you know, we've redone different things move things around It looks amazing now But really this worked really well for me And I think mostly why this worked really well is because I was the product owner. I was the project manager I was the developer. I was the QA. I was the judge jury executioner I was the dictator on this project and it's really easy to get along with yourself Right so that base was covered my team was me and that and that really worked out and even with my Short hair and glasses at this time. I was still mostly dreadlock Kelly just getting the job done So the business evolved and grew and it's got a couple of locations and you can't really see inside on the left Hand picture there, but it looks great. And this is another location and Things have changed quite a bit well, I'm actually I'm not really involved in it anymore and I'm definitely not allowed to pick up a hammer anymore when When they want to do something it goes quite a bit differently there are specs and requirements and statements of work and we get bids from the contractors and This works really well This isn't like invaluable for them because they need to know exactly what they're getting from who and when and what it's Going to cost and it needs to go exactly when it's going to start You know and because I put a budget on it and they say this is what we're going to do You know so like I think eyeglasses Kelly would be proud that this much effort goes into these things This is a picture of an office space that last call media is Working on moving into and we have to do a lot of construction and we've got a hat We have a budget for it and we need to know we don't want just something like what we wanted We want we're going to hire somebody and We're going to get and you know getting a lot of suspects. It's all getting planned out It's going to go a certain way and we're going to get this. This is what's going to happen In contrast projects that are done internally go quite a bit differently Who here works at a place where projects get done internally buy your own resources for your own resources? Right proud, you know, I mean some of you may and it's great if you do but you probably don't prioritize spec writing and and and a lot of like planning of the deliverables and this is exactly what's going to happen How it's going to go right so as software developers we we prefer the agile methodology right so let's Let's take a look at this right group of software development methods iterative and incremental development requirements and solutions evolve through collaboration between self-organizing cross-functional teams Adaptive planning evolutionary development time box. This sounds awesome, right? This sounds amazing this sounds like everything that we want to do to get the job done and None of what we don't want to deal with just I don't like doing that. I'm just not gonna do it I'm not gonna waste my time. I'm just gonna I'm just gonna get to work So almost intuitively we know this can be more efficient this is a lot like Sounds a lot like when I was building that computer store and then and even afterwards when when it wasn't just me as the sole developer Designer dictator of the whole thing even it was just a few of us We had a limited amount of money and we wanted to do a certain thing and we just did what we had to get it done Right so agile is delivery driven and back to that beginning I'm gonna I'm defining it as something like what we want delivered Delivered when we want it and within budget right and this is really like I don't know It's not really the case anymore, but I remember Several years ago everything was beta Right because it was just we're just getting this to market use it. Let us know we'll fix it on the next release There's some you know, there's some weird brick colored wall We didn't like the paint color, but we didn't have time. So just you know, just try it out it's still gonna work and You know the beta thing everybody's kind of used to it, but that's kind of a It was kind of a sign where people were just delivering things getting things done getting them out And I think it still continues to this day except the beta term has kind of faded away a little bit But it makes sense where if you're on an internal Internal project doing a project for yourself. You've already hired everybody. You've already done Done your due diligence on interviewing, you know, this is the best team you can get So why do you need to spend all this time with scopes and statements of work and and spec writing? When you've already got you're not you're not putting them on the hook for delivering this certain thing Necessarily in this certain way you've hired them. They're just if they hit a snag They're the best team you've got just work around the snag so So it's really it really works well on an internal basis and one of the things that is happening is Consultancies are either pushing for or being approached by clients that want to do an agile project But an agile project does have its pitfalls too like at the beginning I asked Has anybody had a agile project go horribly it definitely can happen. It can go terrible an agile project requires an Extremely solid relationship between everyone the whole team and when you when this is this is a solvable problem When you're internal and your team is your team and your product owner is on your team And you can do more training and get to know each other and you can build a Trusting solid relationship with each other, but when it's a new client You don't know you don't have that solid relationship if it just happens and that's just magic, but good partnerships take work So imagine a scenario right and this may have happened to some of you where so many different directions Evolve mid-project right here's the scope change that we're all we've all committed to being agile to adapt to and no problem, right and Gridlock develops somebody wants to go a different way. It's just before QA. This isn't going to be good The but your agile right you so you can do this I've now got a license to change scope as much as I want because you're agile and gridlock happens and You're spending more time Being agile dealing with these changing requirements and time runs out right and what gets delivered on time right because it's time boxed and Within budget because it's you know, it's fixed bid in this way Leaves much to be desired. I don't know if you can see that. It's really small It says leaves much to be desired and what that's you know You can't read it because you barely got anything because you spent all of your time as a poor team Being agile so it happens Totally happens. That's cool, right? I like did this arrow thing Cuz I'm I'm working on being a good presenter Who's had something like this happen to them on one of their projects? two three be honest right Your agile right? I'll just keep changing my mind and you got to deliver something that I like Okay, so right look alright, so I didn't see that many hands But what about these scenarios like somehow you you found yourself on an agile project with 20 decision-makers? Now everybody's got to say right universities and large corporations are great at this You think you've got the the the the stakeholder, but then they bring in their stakeholder you know right during QA or One stubborn pixel pusher right like I want it to match the psds does not match psds like right to the pixel or one time when When very early in my career, I had a client that didn't want to use Photoshop But she was very particular about where things were on the page and I allowed her to talk me into Sit down sessions. This was a long time ago. I don't do this anymore where move it a little to the left a little more to the left one Perfect Okay Great and then you know so the part of the agreement of going into this is like well I've got a bill for my time and then you know after you know weeks of pixel pushing The the budget was kind of blown and she wasn't completely happy, but we worked it out, but that happens or scenarios where Let's see You know someone's on the project and they just won't their thinkers, right? They won't stop brainstorming about better ways to brainstorm like let's talk about this This this project this process could work better, right? You're trying to be the builder and the Improver and the producer and one key player and the whole entire thing is Coming up with ideas all along the way. It's like just put a freeze on this Because we need to deliver something it gets it can be really hard Or you know trying to switch gears just before QA totally happens I've got a new idea super critical. It's got to go into this release. You guys can do it Said nearly every project ever It happens, right? It takes an extremely solid team to effectively navigate these potential pitfalls Somebody wants me to sit down with them and push pixels I now have years of learning on how to appropriately handle that request When we start a project with a client we refer to it as an engagement No matter your chosen dev process. This is pretty serious. This is a big project It could be a lot of money to them They're gonna take it very seriously you need to work together and it's commitment on everyone's part the client's part, too Here's a very stock picture of a very stock engagement I don't think they all go like this anymore, but this is a Ring on the finger So a project kickoff it is an engagement you're a team now a partnership with a major goal in common Till site launch do you part unless you do? Post-launch support and then you renew your vallas or something So either way you're gonna get gray hairs where you're going or a few enough gray hairs that you'll pretend They're not really there Upfront open honest communication is key to these relationships Especially if you're going into an agile project You've got to be a team but also if it's waterfall to they've got to respect that it's fixed bid and not push scope They've that's their commitment And so you've got to hold them to that in either process as a commitment. This is serious This involves having each other as as a priority in the team The most successful partnerships will know where they were where they're going and how they will get there, right? So a lot of times engagements end up leading to a bad place because there wasn't a lot of communication So You may recognize this type of picture, right? This is the process we all know and love. This is our old ball and chain if you will It's got the typical sequential Development process we're going to do our requirements and our analysis Then when that's all set, we're going to design it Another term you may hear a lot of times throw it over the wall To coding you do your stuff coatings all set testing launch maintenance easy-peasy very understandable All order no chaos Wonderful, right? but It's become notorious for being inefficient because if this is like a year-long process And you're trying to get all this stuff done up here You're doing a lot of guesswork and a lot of padding and it's really irritating to spend all that time on it and you're you're putting your As as a CEO of a company on this process I'm going to be expected to sign my name at some point like this is what's going to happen. I promise And that can be frustrating that can be like I don't want to do this anymore. I just don't want to do this stuff, right? Maybe time consuming and inaccurate Every step of the way needs to be planned Perfectly so that this container is the right size For the stuff that happened in these two containers so that it fits And it needs to be at the right angle so that it flows down and everything needs to Happen at the right time so that when you get to here it's on time and with budget just like you signed for And another thing that happens in this thing is you end up getting really adversarial with your client, right? because you've got to protect this because they're having ideas all the time and right And anything that changes mid project you have to consider a change to scope hold on right So here's lucy. She's got a new idea This new idea could potentially blow the whole project to pieces and you need to find that out You can't just say okay because they're not going to care that you were so accommodating mid project when they're things off the rails on launch day You've got a backtrack you've got to go right back to that whole waterfall thing and make sure can we fit this idea in How does this change everything the whole development structure could need to be restructured to avoid catastrophe, right? surprise scope change Right, here's lucy. She thought it would be a critical good idea for the footballs to be on shoulders Right on launch Who here has had something like this happen to them, right? It had you just want to like strangle somebody How can we prevent this we need to prevent this is Right and this happens in agile too because you're agile You can just you know, you can just kick it off the shoulder at the last second. No problem But all right. So this is the incumbent process is where we're coming from I think we all know it We can all be good at it. You can I propose And we'll keep going after this proposal that we honor and value its strengths at least right Especially for the clients that desire require this it can feel really chaotic being a client And going into an agile project where you don't have that trust And you're on the hook to your stakeholders for something really good All you've got is your budget and it's really hard to just hand that over and don't worry boss We're gonna get something like what we want But they'll they'll spend all of our money the money that we've given so it's you know within budget And we'll get something like that on time So when you when you plan all this out when you do all this planning When they need you to do it, it's really valuable for them and and clients are worth it They're your clients or if they're not worth it then get clients that are worth it um right so There can be a lot of unknowns and it can feel really chaotic if you're not planning everything out So go back, you know, if you go back in analogy think, you know, preenum These are oftentimes seen as good ideas in hindsight Or you know, maybe just some really good solid upfront communication before Engaging Here's a little data because data is cool um This is an agile process and a waterfall process And this is basically I'll I'll do another slide, but this is the estimate And this is like oh well, we'll get something like what you want And then here's what tends to happen anyway You know give this huge ballpark from all the ideas you're giving me it could be somewhere in here And it tends to just balloon out And the waterfall process is basically you win some you lose some and we track all our projects and our time spent And when you average them all out This is this is kind of how it goes and I do also want a small tangent from a business perspective from the CEO's chair The difference between these two processes for us on a business standpoint as a consultancy being asked to do these is Change your mind all you want. We're billing hourly. We'll get those extra features in an additional sprint The waterfall process we just signed that we're going to do this for this amount of money So remember we got a protect scope So the green is the estimate And the blue is design development project management qa and as uh As you get in the process and it starts working and clients see what they can do And they they realize that that your agile and you can change your mind Things grow right and and it tends to cost About what I've ballparked at the beginning when I heard the spew of initial ideas Um, but basically the thing about agile that is required here for this to not be a horrible experience Is while you're going from here To up to the top up there you need a lot of communication and you need the client On your team in the trenches with you so that they know that as this thing was ballooning It wasn't happening while you were just playing xbox They were there In like a ticket tracker is is preferable. So they're making the requests. They're seeing the back and forth You need a lot of transparency And here's uh, the the waterfall one fixed bid Kind of an estimation by third, you know by thirds we're going to get this thing Here they they they creeped us for some scope change and we accommodated and you and you win some and you lose some All right, that's just kind of how it goes And the client gets what they're what's promised and there's a motivation on your part To be really efficient because you've got to win some, you know They they got us on the scope. We accommodated. We've lost the last five in a row. This one's going to be super easy We got to do this right. We got to get this done. This is the one where we're going to make up for all the past stuff So So you so you're you're uh, you're motivated to be efficient. So let's look at some efficiency stuff, right? This is a burn down chart. Who here knows what this is? Don't get me wrong. I love I love this thing. I love it, right? So you know what it is your your hours and your tasks are your hours are going down your tasks are getting completed and When comparing efficiency Insofar as as what can happen in with agile methods with scrums and stand-ups and product owners And scrum masters and burn down charts and backlog refinement. There's even scrum of scrums, right? You add in all this stuff. You're adding order to to this chaos of let's just get things done And and maybe it'll work out you're adding this methodology and that can be a really good thing But it can also, you know, it can also be a bad thing when you have a whole team Of people making and analyzing productivity reports where a lot of the times what happens Is the devs get good at gaming the system and this is a real quote From every developer I've ever talked to about this chart. I've heard this called a burn-up chart I've heard this called. I'm gonna burn this chart down Where basically it's like well, I've hardly done anything but my charts look amazing, right? So agile can suffer from inefficiencies too One really starts to wonder when comparing efficiencies between waterfall and agile It's sort of like who's more efficient at eating treats, right? This guy cookie monster Or my daughter One's mess is on the face and the other's mess is on the floor We really when we're comparing these two methodologies We really need to be careful that we're not comparing the worst-case scenario of one With the best-case scenario of the other And I'm gonna steal this heartwarming moment right here To give a little insight to one of the main takeaways from this presentation And that is that people do projects Not processes people Over process we need to value the team and when the when it's a consultancy and the clients coming in They're part of the team And we need to we need to care about that we can't just agile all the way all the time We're not going to waste time on specs. They might really need the specs So but agile is taking over. I think for really good reason I think that it really fits in with how we like to develop and how we like to get work done And there's been a few reasons for its takeover It's now an ongoing business needs software modification is so you hire the best team you can get and they just get to work And so like it's like internally at my business. We're going to do something I don't want people wasting a bunch of time Covering their bases because on the deliverables just start working. I interviewed you. I love you. You're great Just start doing the job And clients when you have clients who here has some awesome clients you guys work great They trust you with everything. They know if something got harder. That's just because it got harder Right, that's an awesome place to be and when you have that relationship You can do more of an agile thing. You don't need to waste time covering your bases Promising deliverables that may turn out to be irrelevant down the road But Getting into an agile process methodology it needs to be done right And for the right reasons So how do you choose? How do you make sure That you're not getting into the wrong process or you're you're going too far with the spec writing Or too far with the with the trust and agile methods so I've got I've got a A way to Decide the way that I the way that I think about this is I feel like waterfall is the safe choice Because you're documenting everything out. You're taking the time you're doing the diligence And things are going to you're planning more planning better for better, right? Planning is safety Okay, so I've got some Criteria because really if you want to do an agile agile project Your team has to prove itself right So good efficient partnerships take work. It doesn't just happen. So you've got a You've got to prove that you can get to the agile Carrot thing that's in this. Does everybody recognize this? Right mario Dented Sorry it's stuck in my head Okay, so but basically You want to get here because this is how to work So you've got to prove yourself, right? If you're a client and you want to go agile you've got to be available and capable of full ongoing participation Because you're part of the team you've got to get in the trenches You must have complete trust in your dev team If something takes a little longer don't accuse them of playing xbox And if you can't trust them you might want to get stuff specked out in a statement of work And you've got to be flexible in the sub tasks because we're all right We are going to get something like what we want and the better team that we are the more like What we wanted we'll get right so A lot of times a client will fail in one of these scenarios And if you dive into an agile project where they're failing on one of these points, I think you're asking for disaster So we have you know, we've we've had projects where They wanted they had a big site they wanted done But the one thing that they had was they had it all the whole process was on paper And they just wanted to make that digital So the spec was it was really clear and they had really good specs And the one place where they failed on this part Was they were not available and capable of full ongoing participation. They all had full-time jobs And they just needed to hire someone to do this And they had a lot of bids on this and it's really popular in our area We only work agile right and we won the bid Because we understood that they had all the specs and we read through the specs It was clear to the developers And it was very easy to say we're going to do these things in this time frame for this amount of money And I signed on it And they went waterfall and we won that project against the other the other companies So for a development team to go agile Right, not that many requirements. You just have to be Highly skilled readily available Extremely dependable individuals You just need to have a rock solid team of rock stars and a lot of us do and they all want to work agile And also a lesser known one I don't know where I don't know if I got this in research or if I just thought of this one But really the team members need to be able to maintain their availability Throughout the life of the project Right because you're not doing all that spec writing beforehand. It's happening during the project if you're lucky There's everything's moving so quickly things are changing a lot of the institutional knowledge of the project That's developing as you're doing it is in the heads of a lot of people So they can't just be coming and going right so And I think that's the most common factor For not doing an agile project. Is it for some reason you're not going to be able to keep the same people on it throughout the project And a lot of times when we're all booked out on agile projects We'll entertain a more waterfall project that we can if it had if it's got clearly defined specs A comfortable timeline and we can just have people chip away at it in their downtime Because people can jump in and figure it out. It's all well documented and it's not changing under their feet So projects are best looked at from the other direction I think that a project has to prove that it can be a waterfall project So there are some requirements for a project to be a waterfall project Does everybody know who these two are anybody? No No hands All right go one guy in the back this is uh TLC TLC yes This is from when I was you know Come Oh, yeah, right Great. Um, I think this is I think tlc stands for the group members. So it's got teabaws left eye and chili chili wasn't available for this for this picture, but um There they are Okay, so for a project to go agile the requirements need to be extensively detailed and clearly defined They have to be if you're getting into a project on a waterfall process If you're if you're signing your name to getting this done, but it's not clear What's going to get delivered you're asking for disaster and the tasks and the steps To complete them need to be outlined fully understood going into it because basically you're saying like this whole thing That's going to happen this whole waterfall construction that we're going to do It needs to be understood going into the process because you're you're making this promise so If a project fails these it just has to be agile a lot of times a client will come and Well, how much would it cost to do this vague idea? And well, we need more information than that. I don't know. Maybe this should be an agile project and we've had situations where a client was looking for work and this the job was so big And that they didn't have the resources to build the statement of work, but they knew they just had to get started And they were asking us, you know To come up with a fixed price for this and we couldn't we wouldn't do it because you just can't do that You can't go down that road And we've been running an awesome agile project for them ever since and we lucked out on the teamwork part. They're they're pretty good team, but But yes, a lot of times projects can fail the requirements of going waterfall And you just you're gonna you're heading for disaster if you sign to that Okay, so the This picture is from the song Don't go chasing waterfalls, right? Don't go chasing waterfalls Stick to the rivers and the lakes that you're used to I don't think they were talking about agile software development but I think this is relevant because the rivers and the lakes that you're used to Instinctively agile, right just let's just be agile. Let's add order to that chaos Or else you've got to chase if you're going to go waterfall It's a it's a requirement of the project that you chase it down You build those specs because your client is worth it in that scenario. All right, so this is uh This is batman And he's selling an agile method, right? We're going to get all the things done It's going to be awesome We're going to do none of what we don't want to do And we're only going to do what we want to do and we're going to get what we want It's going to be great Agile needs to be done for all the right reasons Slow down keep it level head the client is your priority Make sure that there's a commitment from their side as well If you sell agile too hard your client your client or potential client is going to get the wrong idea And this is what they're going to hear we'll walk through fire for you change your scope all you want I don't you know, it doesn't matter. We're agile You need to set proper expectations So i've got this poem here. This is one of my favorite poets This is a poem where To what and to walk across the floor To an old dresser with a cracked mirror See myself ugly grinning at it all This is this is getting something like what we want And being proud of it and working hard grinning at it all right people over process The health of the team when it's a client and you you're each other's priority and the health of that team is the priority Followed by the tasks at hand You need to work together no matter your chosen dev process. You're partnering on something very serious It will be great at times It will be really hard at others good efficient partnerships take work. They don't just happen Waterfall ones and especially agile ones your team the clients the team if you're a consultant And you're getting approached by clients that want to go agile They need to make the commitment. They need the proper expectations. They need to be in the trenches with you You need to share the responsibility of the project. You need to have commitment from everyone involved Communication early and often to set honest realistic realistic expectations are critical You need to have confidence and humility You need to know how to be have a partnership and it's really important to value each other You need to determine what process is best for you as the team going into it. You need to determine it together Commit to it together And then walk through fire together Thank you This is all yeah, um, my name is taco from global rail in the Netherlands Um, thank you very much for your story. Um, I think it really went into the essence of how we want to work And how we want to build these relationships with the team My issue is can you go back to the slide where you compare the agile data with the Waterfall data, oh the loose averaging of averages Okay, because Um For me, it's a it's it's fundamental Uh, yeah, here we go. Yeah For me, this is a fundamental thing Because on the right side you say well, sometimes you win and sometimes you lose, right? We've seen this we've had projects where we're like, wow, absolutely got nice margin I'm I'm also the founder of my companies. We look at the margins And then we have this thing going up, which means like, okay, we put in more hours than we budgeted and We're losing money and sometimes we lose a lot of money And especially when you're a small company, you don't have to buffer Or where you do like two or three wrong estimations This can really hurt and it can really damage your company. Right. So so especially because Yesterday we had a discussion and somebody said, oh, you must be from Wunderkraut and you have all these developers No, we're actually a small company and and if we Get this wrong a few times it really hurts So my point is if you look at this and you say, okay, we've chosen to do this waterfall because we knew the specs And we you know, we we we kept this constraints We still weren't able to make a right estimation and my idea is You cannot estimate the amount of work For a project beforehand Like never you cannot do it cannot be done If you keep this in mind then it's like we're trying we're doing our best here and and you say well, I think it's a safe choice Like the waterfall safe choice I don't I don't agree. I think it's a risky choice. It's the more risky choice for both your client and for you I think the safe choice is agile and small companies Should are better off working agile taking less risk Because you cannot estimate beforehand just count. Well, yeah, I'm not really sure what's worse Getting into a poorly a poor relationship on an agile project or being a little off because you didn't spend enough discovery time I mean we ask if if we aren't sure about something We'll ask for a pre project of discovery time where we'll ask for payment to spend all the time hashing these things out and for some projects where that just seems impossible that fails My project thing where you just can't clearly define what needs to be done. So we won't do those projects This happens Right here where where you lose some and I and I remember, you know years ago You you just you need the work so you get it in their budget and you really lose some and you might win some But this happens more now. I think because we you get pretty good estimation. I think Where we've accommodated the client because we think we want to impress them and we've let them creep scope a little bit And we've calculated that loss and that loss is actually viewed as an investment in the relationship And then sometimes it's easier and you just win but right. Yeah, when you start out It's super risky and annoying and frustrating to be put on to to need to to the money To get the job And to sign on it and basically because you're hungry you're signing too early. So that's a whole other that's a whole other thing Yeah, so estimation are important and Also, I like to say that the trust you've mentioned is very important. Also the role of the product owner is something we see that if the come the person is Not tech savvy, for example, or not able to give a no-go decision. They should not be a product owner And in Holland we even have companies that say no the product owner is something for someone from our team, right? There's a lot of this like the guy from four kitchens has been doing a lot of work on what he calls consultancy scrum And in in the case in that case he's got Clients coming and they're already committed to agile and they're they're saying they want to do agile And so now there needs to be a develop a way to Make them good product owners or good team members so that the whole thing doesn't fall apart mid project Hi so To summarize perhaps just one angle of your of your kind of presentation or talk You're saying that some projects fit the waterfall model because they're well defined And agile projects are perhaps more risky because the scope is not defined Could you explain why you can't do a well defined scope project in an agile way? Oh, no, you totally can and that's why do we need No, you need to you need to honor and value the process the the writing of the specifications And I actually think you should bring that in To the to an agile process the more spec writing the better. Absolutely. You just don't do it all Upfront you still have to define the work. You're otherwise. How are you going to do the demo at the end of the iteration? How are you going to present what we've done if we didn't know what we're going to do? How do you commit to To a chunk of work and an iteration if you don't know Well, I think we still need the waterfall process because there are still clients that need it to some extent Where if they're a university and they're a great client and you really want to work with them And they have they don't have the time to be on the team And they have if they had they have the specs Absolutely. No that I would totally agree with so, you know that you were asking earlier Who's been on successful agile projects and I said me and who's been on bad ones and I said me And it's not to do with the scope. I've found in my experience. I've been doing agile projects for about five or six years now team leading Um, it's to do with the lack of the product only needs two things They need to be available and they need to be able to make decisions. That's it. Yeah, exactly. Yeah And if you don't have that Then you can't do agile. So it's a really what we're saying is some clients Can't or don't want to do agile. Absolutely and those clients maybe should do waterfall Yeah, and when and really what spurs this is they're going to fail anyway, sorry They'll do waterfall and then they'll fail. Well, you're right I think what spurs this is I think consultancy or kind consultancies are over compensating a little bit and they're getting into these Projects with clients doing agile where they shouldn't Fair enough and so this kind of gives a formula to those consultancies, I think I'll try and get the last word. No, honestly, I'm not trying to get the last word But what I was going to say is then those people just shouldn't do the project They don't know what they're doing. They're not available to make those decisions. They can't define the scope Stop it You're wasting money. Oh, well, you know, if you if you've got a client that can't define the scope But they've got enough money and they want to get something like what they want And it's really critical that they get this particular product out And you can kind of feel like they're going to be a good team and they pass, you know They make the hurdles and they get to the agile side We'll you know, we'll just work hourly for them And sprints and we'll just work with them We'll we'll define the sprint at the beginning and just get it done And get them something like what they want. All right