 Okay, we're ready to get started. Thanks everyone for coming. We decided to do a couple of panels in this track, the planning for Drupal Track, because sometimes it's a lot more interesting than maybe listening to just one person for 45 minutes. So we'd really love it if you guys would get involved and ask questions. And we don't really have a very strong agenda. It's really about hearing from you guys and any questions that you have. So today's topic is selling agile, which I think is something a lot of us struggle with because to a lot of us it makes sense, but it's a difficult concept to explain. So we've brought some practitioners of agile to varying degrees along with us. And this isn't at all about kind of, how to do agile or rules or anything like that. It's really just about the language and the kind of strategy around your approach to agile for your organization. So I'm a client service manager for Previous Next in Sydney and we are a Drupal shop. We do only Drupal and we do mostly agile, I think it's fair to say. I have probably a little bit of a different perspective because I've always done projects in an agile way and so it's really actually hard for me to understand the waterfall approach at all because I've seen how successful projects can be using agile. So for me, it just makes sense, but I know that that's certainly not true for everybody. So I'll just have each of you guys introduce yourselves. Hi, I'm Si Hobbs from At The Moment Technocrat. I'm here in my previous capacity as sales support, technical product knowledge and supporting the sales team at Technocrat. I'm not sure if there's anything else I can add to that, I'll pass you on that. Thanks. My name's Snow, I'm from Holly Sydney where I am Chief Problem Solver, I'm told. Which means I do everything. I'm Jason Cochlan, I'm the client service director at Previous Next and unlike Pam, I haven't always done agile. I have done it for a while now but predominantly came from a waterfall background. So I do have a bit of a perspective between the two. So, but as you're probably here today, I'm much more in the agile camp these days. So I guess we can start off a little bit with a little bit of kind of background around how you approach agile, like why do you do it and what are the sort of benefits as you see them? Obviously, before we sell it, we should know why we're selling it. So this is interesting for me to talk about this because I've never been one to push the selling of agile or not agile. I've always been at worked with clients to understand what their outcomes that they want and how to best deliver those. Often I find that agile, mentioning agile with a client simply makes them uncomfortable. They don't understand what it is, they don't understand what I'm trying to sell them. You end up getting into that conversation where they start to perceive agile as being time materials. So in a sense, I think that not talking about agile is quite important in many cases. But by the same token, I'm trying to give the developers who are going to deliver the project the best experience possible and agile is the best way to deliver outcomes to the client. We know that internally and really the question is what can we be doing as far as the contract and to enable us to deliver, a development team to deliver in an agile way? Because the truth is only one out of ten agile projects are really truly agile as well. So I'm really more looking at what's good about agile and how much of that goodness can we introduce into this project? Yeah, I think from my point of view, I think agile is something that is a term that describes the way we've worked mostly for a very long time. And at various points in our past, check into past, we've tried to force ourselves into what at various people have called critical chain project management or other things that really mean that you've got a whole lot of people waiting around for somebody else to finish which has caused problems for us in the past. I think in terms of describing it to the client, I wouldn't necessarily jump in straightaway and say this is agile. I would explain our methodology around multiple tracks moving forward concurrently across interaction design, visual design, feature design and action content. I treat that as an agile track as well and how small components of these four tracks get built or delivered or designed along the way with a lot of hand-holding and meetings and workshops where things are presented and things are discussed and worked out so that as things evolve, I think clients are reasonably receptive to the idea that they don't always know 100% what the outcome is going to be and with a methodology that's more fragmented or fragmented is probably not the right word, staged, so staged approach and then we start talking about sprints and variable length sprints and design reviews and feature reviews and live prototyping and all these sorts of things. And then I can say this is sort of like what people call agile. And actually I've started using some strange words from other domains as well to mean similar things like I'm starting to use the term continuous integration even though it means something else in the tech world. What I'm trying to describe to the client is the process of continually integrating ideas, designs and features and content in an ongoing way throughout the project so that we can respond to change or respond to scope changes or budget changes or timeframe changes without necessarily changing the envelope. So I think, yeah, I would say our processes has been that way and at various times we've tried to change it to make it more strictly one way or another, usually towards waterfall which doesn't really work for me. I would agree completely with Sonos note on that one. I would even avoid, I would completely avoid using the word agile and certainly wouldn't ever launch into talking about frameworks or scrum or sprints or anything to do with the agile methodology or any of the frameworks associated with it. I think what you're doing is actually selling an approach and it's your approach and it's the way that you have determined that working in an agile way works best for you and works best for your clients. So I think working with agile or working in agile way is just, it just makes a lot of sense and there's a lot of things that you can do that are very sensible approaches and I think when you explain those to prospective clients that they will see that sense and it's about building a really high level of trust and a lot of collaboration with the client so that essentially they feel that you're not trying to screw them from the outset and that everybody's really working together to achieve what's the most logical outcome for the project. It's funny, you both said we try not to use the word agile because we don't want to scare them but I think at the end of the day it doesn't matter whether you use the word if someone wants a fixed price, fixed scope contract. I mean that's what we're really talking about here. We're talking about not doing fixed price, fixed scope. So if you're not using the word agile and you're just sort of describing the approach, I mean there would come a point where the client would realize that having said that it's not a TNM arrangement that is what they might think at first. So I've been in pitches where they say, wait a minute, wait a minute. I can't sign a contract with you unless I know exactly what I'm gonna get for exactly how much money. So how do you answer that question in the pitch I'm saying? Well I think you do have to go to some length to explain that the whole idea of fixed price, fixed scope is a complete myth. Anybody who can claim to know all of the needs of a client at the outset and give them an exact price and stick to that is aligning to them. And I think the way to explain that to them is try and engage a little bit about their requirements and look and try and assess quite quickly what their wants are versus their needs and then explain to them how you would be working with them to prioritize those things and actually save them money to get a higher value outcome. There's no reason that you can't provide them with an estimated budget and I think you can still talk about fixed costs but not necessarily fixed scope and then you can work towards a budget that they're comfortable with. Most clients are very uncomfortable giving you a figure if you actually ask them the direct question of how much money have you got to spend and they'll get very cagey about it and if you haven't built up that little trust with them as yet. So you need to be really sticking those conversations to get some sense of what their scope or their project looks like and I think most of us have enough experience to give them a relative estimate of what their budget might look like and that's pretty much what any other organization would be doing even if it was fixed price, fixed scope. The first thing anyone would do would look at a project and say, well I think that's about 150 grand and that's based on experience and generally if you've been around for a while that's probably pretty close to it. So you can do that and provide them a lot of backup information around the actual requirements they've got, give some relative estimations, get them feeling a bit more comfortable about the fact that you've thought through what it is that they're asking you for and talk to them about sticking to a budget. One thing I like to do sometimes is come at it from a little bit from left field and tell them that we actually really don't wanna spend all your money and for us a successful project will be to actually know what your budget is and come in way under that and still to leave you an outcome that is really a successful one and one that everyone's happy with. Yeah, that is certainly a tricky question because everybody does tend to want to know at the end of the day even if they agree with the method they do tend to want to know what they're gonna get and how much it's gonna cost. So the way I think we deal with it is that we do start with a fixed feature set and a fixed budget but we do explain the process that we go through quite clearly and how we handle change. And I think if they know how change is handled up front and how feature in, feature out that sort of process is worked through and if there are ongoing reviews of all of the parts of the project internally and externally and they see that level of care that you're an attention that you're bringing to their project, then that becomes a value in itself and they are more flexible with changes to scope or budget or time. I lost my train of thought there, excuse me. I wanna focus in on one aspect of responding to say a tender or a request for quote and that's the ubiquitous spreadsheet of requirements. There's often a column that asks whether you're going to meet something completely or partially or not at all. I think there's a real tendency to feel like you're in a competitive situation and that if you don't answer yes to all of those questions that your response is kind of compromised. I think if you're dealing with a client that's not willing to look at your responses to each of those questions, you probably don't want that client anyway. Just being brave to look at something and go, that requirement is going to fight against Drupal and saying partial and saying answering partial because it looks like this is not in your best interest. We would like to spend some time to understand what your requirements are further and deliver something along the lines of X1Z. Sure, it does create other complexities with how you size that and you've got a pad for risk and so forth. But when you get into these very fixed requirement tenders, they're all padded for risk. Everyone is quoting over and above what it really would take to deliver that client's outcomes if everyone was doing it in a completely lean or agile way. So I think just being willing to be honest against those requirements and dealing with each of them as an expert and saying that's not in your best interest and just being willing to lose it if the client's not able to understand that approach. I think one of the other big challenges and sort of counterpoints that clients tend to have when it comes to selling agile is it seems like a lot of work for them where I think previously you'd spend six months working on a document, you'd hand the document over to a developer and you'd expect in six months time that you get something back and this idea of kind of a daily meeting and constant questions and I think it's daunting to clients that's a little bit scary. How do you approach that angle? How do you kind of make them feel a little bit better about, you know? Obviously the idea is that the time they put in is time they'll save later and it's worth it but I think the idea that it might be sort of a full-time job for them as well can come as a bit of a shock. I'm gonna take the opportunity to focus on one thing that I think the client loves about agile is the notion of periodic demos two weeks or three weeks. We know that it's at the end of a sprint. We don't, you know, when you're talking to a client you're really saying you are going to be able to see progress every two weeks. The first two weeks you will see some of your website being built. We're not gonna go and hide in a room for three months and then come up with something that you don't want. And so that's where you're really taking advantage of what the good things are about agile. From a client point of view, you know, what's gonna give them comfort and you're pushing them up front and you're saying you're gonna really enjoy this process. You're gonna feel like you're in control and you're gonna feel like you can escalate if something looks like it's going wrong. I'll take your lead and focus on a small part and I'll use content as an example. I think often with the kinds of projects we work on there's a heavy requirement on the content editor. And I think one of the things that I'll say up front to a client is that this is the largest, this is the most underestimated part of the project from your point of view is how long it's gonna take to populate your site or your app or whatever. And that fits really well with our model, which is live prototypes and live websites early on. So content types from a Drupal point of view, content types fleshed out and evolving. And that will also show us what your content's really like, where which fields are missing and all of this. And this will give you a speed up in terms of those scary deadlines that you've placed on yourself and we can make that easier by splitting this up. So you'll get this feature on this date, you'll be able to enter those pieces of content or we can do automatic imports or whatever. You'll get screencasts on how to do that, those just those jobs. So these are also in smaller units, like two minute screencast, how to do this, how to do this, how to do this. And instead of exploding their brain with a manual or an hour long screencast on populating their site or one full day workshop on how to manage your site, they get lots of little ones and that helps us and that helps them. And I think in that way, what was the question again? I've gone off track. Hopefully I'm answering the question. But I think looking at it from their point of view as well. And I think we're really good at explaining how those four tracks, my four tracks, interaction, design, content and function, how all of those running concurrently give them visibility on their project as it evolves, gives them opportunity to change as the project evolves. And from our point of view, it gives us visibility on black holes that we haven't seen, things that we haven't fully understood because they haven't been able to verbalise it or document it. We're just communicating. Everybody wins out of this. And as you pointed out, while we're having our brief, this is not, this tries to also break down the antagonism that can be the client provider relationship. We're not against each other in this project. We're weaving ourselves together and all moving forward together. Well, to answer your question, Pam. Maybe you can tell them the question. Byte's very nature and agile methodology needs to be agile. So I think if you have a client who you're having trouble getting across the line with that sort of approach, then you need to adapt it. So if you're running a scrum framework or using a scrum framework and you have daily stand-ups and you have fortnightly reviews and the client finds that too daunting up front, then you need to adjust it to a point that's comfortable for them. And I think if you bring them along for the ride, you'll find fairly quickly that they start to engage on just very few clients that have ever had that, once they get involved in a project that is running in an agile way, most of them love it and wonder why they've never... If any of you guys have any questions, you can feel free to go up to the mic or if you just want to tweet your question, we'll read them off. One other topic I wanted to talk about was, oftentimes you meet with people who are kind of at the project level and they say, look, I totally buy it. I think agile is great. There's no way my boss is gonna go for it. Is there anything you've found very effective in terms of empowering those people to sell agile inside the organization? I mean, do you have any kind of experience on where you would approach that from and how you would try to drive that change? Are there any resources you recommend or kind of training courses or... I didn't tell this question to them before, so... This one's new. If I was confronted with that situation, I would really seek to have an audience with that person. There's no... I mean, it's a bit of a red flag to start with if the person who's signing off on this is not involved in that conversation. I mean, and it's really interesting that you do often find these really amazing resources on the client side who understand agile, who understand, you know, how to manage the change in a project. You know, they just get it. They're smart. We've had them with a few of our clients and there was one contract that we did which we wanted to deliver in an agile way where we actually wrote as one of the assumptions that a specific staff member wouldn't leave the organization because we were gonna rely on them to handle all of that discussion on the client side and get around change. So, yeah, so that's really... If you can't get that person in the room, you're in trouble, probably. I actually have no answer to this question. Again, I would just say, you know, it's... You've got to have that person at the table. You've got to have the owner of the project and the person who signs the checks at the table. It's got to be about personality. It's got to be about your personality as a business person and their personality as an organisation. And if they don't match, then, yeah, red flags. Um, yeah, Simon's actually absolutely right there. If you really need to talk to that person and get an audience with them, if they're still not budging on that front, then I think you need to find buttons to push and probably usually the biggest one is money. So, if you can somehow cut through on selling in how effective the approach will be and how much money they're likely to save. Very difficult to quantify, I know, sometimes. But you need to find a carrot to dangle to try and get them into a room and actually have a discussion about it. But, like Simon said, if you can't actually speak to that person and they're gonna dig their heels in about it, you're probably in a lot of trouble. Well, you guys are making it sound really easy, so I don't even know why we're here. Anyone can do it, right? No, I'm actually curious though, whether any of you have had the experience where you just tried to go in and sell it and you totally bombed. You either got totally blown off or you said the wrong thing or, I mean, are there any mistakes you've made that you thought, all right, I won't do that again. Whether it's trying to be too specific or making it sound a little bit too much like TNM. Yeah. No, I just wanted to say I've never done anything like that. No, I think the worst mistake you can make is going to be evangelical about agile. And I was probably guilty of that when I first started working on agile projects because it was a bit of a revelation coming from a very strict waterfall background where you are the project management dictator and you're sticking to this budget and scope and nothing will stop you achieving that. And coming to the realisation and digressing a little bit that you engage more with your team and everything is to be working in. But I think, yeah, that would be one mistake that I would have made in the past and that is being evangelical about it and then they just glaze over as soon as you start talking about squam and frameworks and sprints and they don't even have them good. I don't know that I would probably say that I blank out on the stakes. So just forget them, yeah, move on. But I guess maybe having said that and possibly answering your previous question as well about tooling the person on the desk is I think there are some very good visual tools that you can use to describe your process without being evangelical about it, sort of taking again these four tracks, breaking each one down, showing how they all fit together and how they all follow a common pattern. And I don't necessarily think that, I mean, perhaps I have learned from mistakes and been and evolved the way I talk about things, but I think that's just because we evolve the way our projects run. And it hasn't been that we've always had these four tracks and they've all followed these sort of sprint-based patterns but slowly one by one each of these four tracks has become part of this rhythm that you go through. And yeah, mistakes, I don't know, I probably would cover from them hopefully on the fly or get kicked out of the room. I have to ask me next year. Yeah, hi there guys. One of the strategies I've found to be successful is to maybe do a first phase of a project in a fixed price kind of way. Maybe like a pilot thing or stage one or whatever. That could just be some discovery or maybe just getting the thing off the ground. Once you then have that confidence and trust with the client, then you can go on and sort of work in an agile way. Is that something you guys have tried or any comments? Yeah, that's a really, really good point. I think almost every time I've sold a project, I've usually tried to take what is really dark and amorphous about the requirements and push them into a phase two. And I've always found that the client's been really responsive to that approach because, I mean, look, they don't know what's hard about their project. They're willing to believe you provide, I mean, they don't really see the downside of it because all you're saying is, we don't need to quote that. How about we deliver the X, Y, and Z for this amount of money and you can really pull out the stuff, the bread and butter stuff, the stuff that's well-defined that you've done before. You've got someone coming off who's done all that before. And you really low risk and because you've made the project quite small, there's even less risk. If you go over, it's not by $3 million, it's by $10 grand or whatever. So, definitely do that. Yeah, good point, Murray. We definitely follow that approach too. Sometimes taking it one step further, which is we offer a fixed price one or multi-day discovery phase, which we call a media workshop, where we sell them our time and we say, well, once you've done this, you'll have a document that you can take to Tender or to the next phase. We'd appreciate it if you'd let us quote on that. Include us in the Tender process, because we're keen on this project, we think it's a great idea. Beyond that, often we'll say, okay, we think that there's a piece here that we can do quite quickly and it's quite constrained and reasonably well-defined. Let's call this a prototype or a Stage 1. And yeah, those things that we don't know about yet. Let's, at the end of Stage 1, let's do a whole bunch of user testing. And instead of you telling us what you think your customers want, let them tell us what they want. And I think that goes down really well and that really fits into that prototype Stage 1 type idea where it's, as you say, it's a smaller piece of the job, the pieces are better defined, so it's less likely to go over. And then we've built up the confidence, we've introduced a bunch of tools that they probably have thought about in the past, user testing, unit testing, usability testing, all of that sort of stuff where you can go, okay, well, we can get some data that you don't have. You're making assumptions. We're making assumptions. We don't need to make assumptions. Let's fix it. Yeah, thanks Mario, that is a very good point. I think it's a really good opportunity to take them through that journey I was talking about before and get a really good relationship going with them. We do that, aim to do that on all of our projects and that is like a definition phase at the beginning where we go through and refine their requirements and do that needs versus wants kind of approach to it. And by the time you get to the end of that, they realise that it's not a time and materials project at all, it's not what you're trying to do. You're actually trying to work really closely with them to define exactly what it is that they want and save the money in the process. Yeah, I think the other piece to that and hopefully doesn't happen often, but I think it also gives you an opportunity to assess what type of client they are and if they say they're gonna buy into it and then you find that that's completely not true and they've been difficult to work with, you've only signed on for a discovery phase and you can sort of excuse yourselves after that. So it goes both ways. What's up? You can fire them, that's one way to say it. Dan on Twitter asks, is there an instance where you wouldn't use agile or is it agile or nothing? Like as I said earlier, a lot of the projects that we do in an agile way aren't strictly agile. I think I've only seen one project in my time at Technicrate that was pure agile. So if it's not pure agile, what are you doing? You're really taking the best parts, the ones that can be applied to the project and using them. So even in a waterfall project, I will always try to introduce the idea of delivering two-week demos or sort of working in sprints in the sense that the team has a goal, a short-term goal, where even if the client wants to see an outcome, but it also helps from a morale point of view or internal point of view to minimise risk to have the team all focusing on a short-term outcome. So, yeah, so I think you're still, you're always pulling the parts that just make sense into the project where possible. Yeah, I think it's, I don't think we're sticklers for it. I think it's just really the way it happens under the hood and small projects maybe, you don't really change your methodology, but there aren't really more than one sprint. Or, again, projects are broken up into a couple of stages and they really form one or two sprints each and so it's not so apparent from the outside what's actually going on, or even internally, really. Or the other time that it doesn't really make sense is if we're part of a larger multi-disciplinary cohort of businesses working on isolated parts of a project and then it's not really, doesn't really fit into the category anyway. If it was a multi-million dollar startup with a bottomless pit of money, agile or nothing, because it would just be one big party, but the commercial realities of what we do mean that that is just not at all possible. And actually, I just wanted to reference something that Dan actually mentioned earlier around the project management talk. The agile manifesto, I've seen it also referred to as the half-assed agile manifesto, and that is because if you did take that approach, it would be a very half-assed approach. So if you haven't seen that before, I suggest having a look at it. Everything on the right-hand side that essentially is discounted are absolutely imperative things, and if you don't do them, you're gonna be in a lot of trouble. And a lot of those things are sort of traditional waterfall stuff like contracts and planning. And so, absolutely, what you do is just take the best bits of agile and blend them together so you do sometimes end up with a bit of a hybrid. I think also, it depends what you mean by agile, because I think that when I think of agile, I just mean I'm not giving you a fixed quote, and I think that that's, I think fixed quotes are never a good idea because I think what ends up happening is, as a vendor, we'll add a lot of buffer because we don't actually know. And it may come in way under, well, sorry, it was a fixed quote, you have to pass the full amount. So I think that the kind of, yeah, yeah. So we should, maybe that should be what we do, but I mean I think it's much more fun to interact with the client and say, hmm, you know what, that actually sounds like it might be an eight hour job. Let's say maybe up to 12, but if we get to eight and we still don't think we can do it in 12, we'll let you know, or we'll say, well, we'll spend an hour looking into it and then we'll get back to you with a better estimate. I just think that approach of constant communication and feedback and iteration is so beneficial because I also think that when you say it's not agile and you sort of write a one line requirement and the client has one version of it and you have what you think it is as well. I just don't really see how that will ever end well and I think the idea of, oh, you want a blog, we'll spend four hours setting up a blog for you. Have a look at it, let us know what else you want. Rather than trying to think of anything you might want up front, make sure you get it in writing, make sure you get it in the contract and then that's what you're bound to deliver. I just don't see how that could ever produce a better outcome than let's set it up, try it out and then take it from there. We're almost out of time, does anyone else have a question? Yeah, one. Our business is structured in a way that we have a development design team in-house working with multiple businesses with various needs and we've been making a push towards agile. How would you encourage the business itself to adopt and embrace agile methods when, for example, you say that you don't specifically use the word agile, you use different terminology to describe the workflow and processes within agile without specifically force feeding them agile? When we're being told that we need to be adopting more agile processes, how would you get that type of business who are very, very entrenched in traditional waterfall methods to do that? Who is driving the change in your organization currently? The executive leaders. Although they leave that, I suppose, defining the processes and communicating that to the business. So they've told you to do agile, but nothing more than that? Yes, basically. Anyone? Did you want to respond? I don't know why I was singled out there. Yeah, it's interesting. So the question really is how do we do this, given that we don't have everybody inside the business on board with this experiment? Yeah, it's interesting, isn't it? I think, you know, because I tend to be steering the ship, I do spend a fair amount of time trying to explain this methodology to people, even though I'm not a strict... I don't follow a pattern, a strict agile pattern. It's just that our pattern falls into users, a lot of things that agile recommends. And that is a hard discussion to have. I've found particularly visual designers. It tends to be a bit tricky when you tell them you're not going to spend 150 hours designing every single page in a website. Yeah, OK, well, my... OK, and I'll come back to that. If you have your management team telling you to do agile, you're probably 90% of the way there, because that's probably the biggest battle. If it was coming from you to them, that you wanted to do agile, that's a massive uphill battle. So the suggestion would be that you, as the team, need to study and look at agile, get familiar with the concepts and the frameworks and work out if it lines up with the way that you like working and how you want to work. If you don't have people within your team who are kind of self-organising, have kind of leadership potential, I don't mean they have to be managers. They need to be able to lead on what it is that they contribute to the project. If you don't have that, then you're going to fail right from the start. You're just not geared up to be able to do things effectively in that way. So I think there's a quote that I came across when I was preparing for a previous talk, and that is there's a view of this that leaders are absolutely mandatory in an agile environment, and managers are completely optional. I wonder if I just have a couple other ones. I have seen situations where you will sell in a resource, one of your own resources, into a client who effectively spreads culture to use a civilisation analogy. Effectively spreads culture in. You offer your tools. You offer, you know, you can use Agira. You can have access to some of our online collaboration tools. That person effectively spreads the culture into the team internally. And so that team, just like when we all first started using IRC to start collaborating with other Drupal people, you get asked, suddenly you've got someone right next to you who's able to go, oh, that problem in Agira, we solve it by doing X, Y and Z. Or this project's doing this and this project's doing that. So rather than being isolated and siloed off, it's a good way if you can possibly get some of the really good agencies to drop a team member in for a couple of months and support your team internally, you will suddenly start to, like, biosmosis a lot of those things will flow in. And so the design question. The design question. And, you know, the four tracks, right? So I think probably design and what I call interaction design has come into this piece nearly, well, I guess maybe content has come in last. But I think going to DrupalCon taught me a lot of these things. All of these Drupal Meetups where you get to listen to a whole lot of smart people talking around front-end ideas. So I think a couple of years ago I listened to Luke Brokker and John Alvin, and John Alvin has done it again today, which was great. So design. Let's split it up. If you want, I can talk about the interaction design piece as well. Design for me now falls into, I wrote it all down, four bits. Four bits. And we use as many of these as we can get past the designer. I think the first thing is, as I was trying to say, they're a little bit upset that they're not going to get to do the whole job. And, you know, they're not going to get to spend, I don't know, I just made up a number, 150 hours. Okay, designers are really expensive, or they think they are. I used to be one, and I was too slow and too fussy and too expensive, so I fired myself. They're not going to, we can't afford to pay them. The client can't afford to pay them to do 20 to 50 Photoshop files that when a change comes in, they have to change them all. And they're good tools for changing all of these files, and I think there's another one I learned about just the other days. Is it called Sketch or something? Who knows what it is? Is it called Sketch? Yes, of course it is. And so I'll be learning that tomorrow. So that's the first conversation. I don't want you to sit down and do this. I can't have it. Oh, but we won't, you know. I can't have it. So the way we're trying to approach it is the first cab off the rank is a, what some people would call a mood board, and I think we would call it style tiles, right? So this is sort of colors, fonts. I say colors, fonts, textures, line styles, and things like this, right? Things that you can fit on an A4 page that will give the client an idea of how we're going to mirror their identity on screen. So you get that right. And this is where the agile thing comes in because we're going backwards and forwards with the client. We're getting all these things right so that when we sit down to do the next bit of work, which may or may not be 50 Photoshop files, we're not wrong. We're not wrong from the get-go. We haven't produced all of these files and they're saying, I don't like it. Once we've got that, then the next thing that we do is design components, which really fits really closely into the way Luke and John Albin have been talking about building design components. So you're isolating components out of the page. And this is where, because we've already kicked off on what we've replaced wireframes with, so because we don't do wireframes, we're doing live prototypes straight into Drupal, and we're showing the design of this. We're saying, okay, well, look there. There's an element. There's a menu. There's a menu and a sidebar. There's a footer. There's a thing. There are a bunch of widgets. These are all your components. Go away and design those. And don't design them with other things around them because, you know, you're going to spend a lot of time making the page balance and then the client's going to move them all around and two years down the track, we're going to plop a different kind of panel in there and a different kind of menu in there and you're not going to get your balance. They're going to work by themselves. So design components in an isolated way, reusable components. Right, so on we go and we start building this out in CSS and applying it to the prototype and towards, you know, as time goes on, you know, the clients have been seeing this. They've been seeing the design evolve and Luke Brooker pointed out that this is a good thing for the client as well or rather this is a good thing for the designer and the themeer because the client has seen this all the way along and they've made changes all the way along and they've adjusted things all the way along so they're not shocked when they see the thing, you know, drop, the first drop. And then we have something called the designer's right of review where they get to put on their fancy hat and come in again and jiggle things around. Okay? Fixed amount of time. Yeah, definitely. Definitely a fixed amount of time. Definitely I double whatever they think they might want. And I think this is where CSS preprocessors really come into their own. We've got everything declared in variables and you can sit down and, you know, maybe you've got browser sync installed and you've got the, you know, browsers at three different page widths and you've done all the responsive stuff and they say, oh, I'll just change the pads here and you make a change in the variable and the thing reloads and they go, one more, reload, and using the inspector and just tweaking a few things and reload. And so this process, I think, gives the designer, you know, I'm pretty sure they don't want to spend 150 hours on, you know, rolling changes backwards and forwards through Photoshop files. So this gives them a really, really clear jobs, which is style tiles, components, reusable components and then the writer review. And I think that sort of treats them as a designer rather than a draftsperson. I was just thinking for a second about a story that might work. As a business owner I would like a design that changes to my every whim. I think that the other kind of important point there is that a lot of people think, and I think that even we struggle with this sometimes, you think, well, the client's never going to sign off on a design unless they see 15 or 50 templates and the easiest way to answer that is if they want to pay for that, they can, but I think if you put them side by side and you say, you know, you can either pay 20 grand up front for designs that we're going to go backwards and forwards with and probably aren't going to look exactly like that because you're going to change your mind, or you don't have to spend that money up front and we can take the kind of agile you would say the iterative agile design approach, you know, it's going to save you. You know, you can be really clear about the value of that and yeah, I mean, if they choose the template way, I guess, hey, go for it. And you can't click a Photoshop file and everything changes when you can click it, right? And this is what I guess sketch is aiming for, but that's you know, that's the big problem. You can't put where you can actually I was going to say, you can't put a Photoshop file on a mobile phone and discover that your thumb can't get there or it can't hit it or something like that. Whereas if we can get it into the prototype sooner rather than at the last minute when we've realised that the designer didn't design all of the things that we have to build, this is why the live prototyping up front and when I say live prototyping, often I say, okay, in the room with the client, okay, with drew boards built for that, just do it then and there. You want another field? Let's put it in. Where do you want it? Over there, okay. What would you do one on it? Okay, there it is. How does that feel? Okay. One of the things we struggle with a little bit as well is oftentimes we get designs from a third party that have been created without our involvement and I think again it comes down to the cost. We can vote to do the PSD exactly as it looks, Pixel Perfect, everything they've said, including all the features they've invented that don't exist or I can give you the minimum viable product approach that it's less than half the time and we can give you the look and feel and the basics and we'll take it from there and they always pick the one that's at the price so that makes it a little bit easier as well. I think we're out of time but thank you all for coming.