Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I am your host Jen Simmons and this is episode 62. I want to first say thank you so much to today's sponsor, FreshBooks, who, really, literally, these sponsors are what is making this show happen. So, thanks so much, sponsors. And then I want to jump right in to the show. We talk a lot about technology, clearly, on this show, and talk a lot about... I try not get too geek with the code, always, because I like to have people who are more on the business side or the design side or the client side totally come listen to the show. And I like to think big picture and the future, but we always tend to talk about technology. There's a whole other side to what makes web projects happen, however. That's... what is that? That's humans. Human beings and money. You have to have human beings to make web projects happen and most of the time you need to have some kind of money. Or resources, time, if it's a small project you can do it without any money but you've got to have time. We're going to talk today about how to manage a successful project, how to get the thing rolling, how to plan it out, especially when it comes to clients and contracts and waterfall vs agile methodologies and organizing projects and all kinds of juicy3 stuff like that. More on the business side and on the how-do-we-actually-get-this-done side. My guest today is Kristin Ellington. Hi Kristin.

Kristin

Hi, Jen. Thanks for having me.

Jen

Kristin is the COO of Funny Garage and she's been doing, you've been doing web projects forever. You're here in New York and you've been working with a lot of big clients and with a lot of big properties, if you call them that. Interactive design, strategy, technology, for websites and mobile apps and games. A lot of fun projects. You and I met because we were on a panel together at a conference last year at Artifact Conference. And getting ready for that panel, we had a lot of conversations along with the other people on the panel that were just so amazing. You just know so much about how to put together a contract and how to make a project happen. [Kristin laughs] So I thought it'd be great to have you on the show.

Kristin

Well, awesome. Thank you. I'm excited to talk as well. As you said, we've had a lot of good conversations in the past and at the end of the day, the business side is really, ultimately, how most projects get up and running. I've learned a lot over my many years doing it and mostly through making a lot of mistakes. I'm here to share a lot of information and insights with you and everybody listening in and I'm excited to dig into it.

Jen

Yeah, so, talk about... will you explain to people. Waterfall and agile are two words that will get used. We use them a lot, constantly, a lot of times, but without defining them. I'm sure there are many people listening who have no idea what we mean when we talk about waterfall, agile. You want to start just by explaining, broadly, what you might mean by those ideas?

Kristin

Absolutely. The best way to run a project is to have some sort of philosophy or framework by which you can share information, share knowledge, set expectations, et cetera. Unless you're doing the project completely by yourself, there's normally, particularly in interactive media projects, there's normally multiple people involved. There's a whole world of philosophies and approaches to how to do this in the best way. Some of these approaches borrow heavily from outside processes that have been established prior to the business of building websites and mobile apps. Some of them are coming from the software industry and some of these ideas are just very fresh in being developed as we, as I said, Funny Garbage, which is the company I run, and many other companies out there, we're constantly learning and evolving our process. That's what actually makes what we do pretty fun and interesting from a business process side. The big buzz in the world of project management process is whether you're going to be doing a waterfall project management approach or an agile project management approach. These have very specific definitions in theory, but in reality everybody interprets them pretty differently. A lot of people end up making their own versions thereof. One of the most interesting things going on at Funny Garbage, coming out of a traditional waterfall approach and really moving to a more agile approach is really trying to figure out what the differences between those are, what are the pieces that work and how do we get our clients on board. In a nutshell, a waterfall approach is really about very definitive stages that you go through and it's a very linear process. Typically, it's design and then planning, then technical development and then deployment. Different people use different terms for these but it's very, very, very linear and one falls into the next. You get all your sign offs and approval for one stage before you move into the next. It's very design heavy up front, it's very paper-heavy, it's very do all of your thinking upfront and get everything signed off on. In theory, cross your Is and... or, cross your Ts and dot your Is, rather. [Laughs] However that works. Then you just basically move into development and the client kind of disappears while your team works away. Then they come back in at the deployment stage where they're ready to launch the app or the website or whatever it is that you're focusing on. Then, theoretically, "Oh, this is perfect, this is exactly what I imagined". And then you launch it into the world. That doesn't really happen that beautifully, of course. [Both laugh]

Jen

Right. Part of what waterfall reminds me a bit of... my father is an architect and that sort of world of construction. Physical, building buildings, physical construction. Where there's a whole plan and then the architectural firm is hired and they plan, plan, plan, plan, plan, and do all these drawings and models and back in the day before computers were used, even, just physical models and blueprints like crazy. And then, sort of, that's done, and you no longer touch any of that. Who knows if that's actually realistic, that's probably not actually how it works. But mostly the idea was, you're going to build a house, you hire an architect, they plan the entire plan, they draw all the drawings, they engineer everything, they get the permits from the government, they make sure that it's all going to happen that way. And then you hire a contractor and the contractor orders all the lumber and all the steel and all the materials that are needed and all the equipment that's needed and then the construction starts. You don't decide after you start building the building that you wanted a four bedroom house and not a two bedroom house. It's sort of like that. It's sort of like, "We're going to do this web project and we're going to plan every single thing we could possible think of ahead of time. We're going to draw everything on a piece of paper and we're going to send it over to the people who are going to build it."

Kristin

Right. That's a really good analogy and I actually use that analogy a lot when I'm talking to clients or people who, they know they want a website but they don't know anything about the process because they don't want to start hearing "waterfall", "agile", you know? They want to hear something they can relate to. Of course things happen in the construction of a building and there are overages and change orders and things like that in the physical construction world. But the reality is, is that primarily they know what they're doing, they move forward and they implement it. And the reason why that works is because the field of construction is a relatively defined and known world. People understand the materials. They don't really change that rapidly. People understand what's required in terms of the construction. There's laws and regulations that are set. Everybody follows relatively the same procedures. Obviously i'm speaking broadly. Some architects are using incredibly new materials that have to be tested, but generally speaking, people know what they're doing, what to expect, and what it's going to cost. That is completely not the case in the world that we live in. And in fact, it changes everyday. There's no guidebook. There's no all-knowing, all-seeing. It's incredibly hard to predict. It's incredibly hard to explain, incredibly hard to get people to define requirements in a way that you understand and to the level of detail that you can make a really, really solid plan and then go off and execute it without their input. Enter agile production methodology, right?

Jen

Yes. Go ahead.

Kristin

Agile is a very different approach, where you're taking little bits and pieces along the way and working in what they call sprints. You say, we have an idea of what the end result is going to be. We define what's called the minimum viable product, right? The MVP. We have a pretty good sense of what that is. Don't necessarily know how exactly you're going to get there. But you chunk up your time in pretty short sprints, two to three weeks, and everybody focuses on one feature or one or two features during that timeframe and then you check in very, very regularly, everyday, and see how that's going. There's not a lot of surprises along the way. There's immediacy to it. There's dividing up something really big into some small chunks and then you can move towards that minimum viable product and then at that point decide, we're going to add more features. Which in a waterfall world might be a quote-unquote phase two. In an Agile world you can kind of just keep rolling with it and the client, customer, gets to decide at what point, "Ok, this meets my minimum viable requirements and I can actually launch this thing out into in the world, potentially, and see what happens." It's much more iterative. It's all about being iterative. It's all about having... it's more like having a compass as opposed to a map. I think a really good analogy is that waterfall is like having a very detailed map in front of you and Agile is more like having a compass and an endpoint in mind. Where you can maneuver around and make decisions about how you want to get there and then ultimately you get to your destination.

Jen

It seems like, with a project that's more in the Agile side, there's not nearly as much time and effort put into planning every detail and every exact, like, trying to budget down to the number of hours every single thing that's ever going to happen for the next two years before you get started. It's just saying, we're going to make a list of all the stuff we want to do. We're going to keep adding to that list. But we know that we don't have everything on that list. We know that there's a whole lot of other things that are missing from the list right now. And as we go along over the next two years, we'll just start adding stuff to the list. And then we'll put the list in order, of a priority, and we'll just decide, "What's the next five most important things to do?" And we'll start working on those things. And then maybe we'll realize that, "Oh, we thought we knew what numbers six through ten are but we're going to change our mind about those when we get to them. But right now we're going to focus on one through five. And, oh yeah, we just thought of 16 more so we'll stick them in the middle of the list somewhere. But let's go back and focus on the next five. Let's just continue to remind ourselves that right now what we're doing is we're building these first five priorities." It just leaves everything mushy and so if you suddenly discover that, "Oh, we thought we were building a..." I don't know what, "... soccer field, But a football team showed up. Now we're going to quickly switch this into being a football field." You can do that because you were just working on five things anyway and you hadn't even decided what number six was going to be, so when you get to six you can switch it up.

Kristin

I think that's true, Jen. I would probably articulate it in a slightly different way. Because I think that... again, everything that you're saying is accurate but those are the types of things that freak clients out, when you explain it in that way. [Both laugh]

Jen

"We have no idea what we're going to build for you. We're just going to start charing you money."

Kristin

Yeah, exactly. I've tried that tact and it doesn't work too well. I haven't had too many contracts signed that way. The crucial difference about Agile vs waterfall is that both o them require a tremendous amount of planning. The big difference is that during waterfall, you're planning primarily happens upfront. During Agile, you're planning happens is a much more evenly distributed way throughout the lifecycle of the project. Agile comes from pure software development. I think that that philosophy works very, very well if you have a set team of people with a set product that everyone's working on and developing with no competing projects. You don't have a set, fixed timeframe and a set, fixed budget for your product. It's really about continuing to develop it over time. A lot of the really amazing, successful web products that we see out there are 100% developed in this way. They're constantly changing and evolving. The obvious, how Google works and how Facebook works. Even other things. Like a Basecamp. Or any other kind of web-based piece of software that's out there. We see constant improvements and constant changes and updates. Well, sometimes they're not even improvements. But we'll just say constant changes and updates. It becomes a lot more challenging when you're trying to use that open-ended flexibility. Which is not just wide open. It's not about just anything can happen. It becomes a lot more challenging when you're working in a world where there are parameters such as fixed budget, fixed timeline, fixed scope in the client's mind. Even competing projects and resources being shared across multiple projects simultaneously. It becomes a much more complex thing and I think that's why a lot of creative shops, interactive agencies are using a blend of waterfall and Agile. Which, certainly, purists frown on. But I think the blend is really where most of us are heading and trying to figure out the best way to combine those two things.

Jen

It seems, in my experience, the part where it gets really hard, is that... I mean, you're right. If it's a startup that's doing a software projects that's got a team of 15 or 50 or 75 developers, and that team is trying to focus on what they need, then Agile is a perfect way to go. I haven't actually seen... I see projects that are planned that way and then upper management comes in and wants promises, very specific... suddenly it becomes more waterfall because they want to tell everybody what's going to get done by what day.

Jen

But when it comes to, like you said, client projects. If you're an independent agency or an independent designer or you're getting clients, the client want, or the upper management, people want to know, "What am I going to get and when's it going to be done? I need a promise. I need a commitment. If I'm going to start paying you $50,000, what am I going to get for that money and when are we going to have this finished?" What kinds of things do you say to clients when they need to know. They don't just want to give you a blank check. They want to negotiate a price on a project.

Kristin

Almost all of my clients are like that. I would just go ahead and say all of them are like that. They want predictability. They want to maximize what they can get for their budget. They typically have some concerns or anxieties or lack of experience or, who knows the myriad of reasons coming into the projects. They're looking for some guarantees. The reality is, there are no guarantees. It's interesting because, how long has the world of doing work for hire, websites and apps been around? I mean, 20 years at the most, right? How many people have been actively engaged in it, in their careers? Much shorter time span and most people are not that knowledgable. This whole fear factor comes in. The thing that's really interested in that in that 20 years, waterfall has become the default client-services approach to project management, right? All of a sudden, this is how it has to be done. I've done two websites in my career on the client side and this is how it was done before and this is the only way to do it. I finally learned this process and now all of a sudden, you're throwing all of this crazy new terminology at me and you're asking me to sign on for a completely different process that, frankly, sounds very open-ended and very much setting me up to fail. That's the typical response. Like, "Are you kidding me? I just learned the last process. You're killing me. I don't understand what you're talking about and, frankly, you're setting me up to fail." Which is obviously not a position that's going to make a client happy to sign a contract with you. So what do you do, right? [Both laugh] I've tried lots of different things. What you do is, you do the best you can to create a relationship with that client because at the end of the day, process is meaningless if you don't have a trusting relationship. I know that sounds really obvious, but honestly it's the hardest thing to really create. The thing that you have to do is to get your clients to understand that you're not selling a product but what you're selling is a process and a trusted relationship. If you can really get out there and create a relationship with a prospective client where they really feel that you have their back, that you understand what it is they need, and even things that they might not know that they need, but that you will, at the end of the day, make them look very successful within their organization, they're going to be a lot more willing to go the route of being a little bit more flexible.

Jen

We kind of skipped over why... in my experience, Agile has worked better and we're sort of jumping into this assumption of, of course we want the client to buy Agile because Agile's better. But it's not because we want blank checks so we can go on a vacation and buy a new car. It just seems to work better. It makes a project flow better and not nearly as much time is needed to put into a lot of paperwork and process, planning that isn't going to come true. Sitting there planning and planning and planning. I was put on a project once where we spent two or three months and maybe $3,000 of the client''s initial budget to plan for them. In the end, they didn't chose us because they didn't have enough budget to do what we said they were going to need to do with us. It's just like, that was a lot of effort put into planning that just came to nothing. A lot of people that I know want to go Agile because it ends up setting everybody up in a "yes" relationship where, when the client says, "Hey, I think maybe we need to do this. I just learned something. We just did design. We've been working on this for two months and I just learned that I think we want this widget over here." That you can say, "Yes! Let's figure out how to make that happen. I agree with you." Instead of saying, "No, I'm sorry, that wasn't in the budget and now we can't add that unless you have money. Do you have the money for that?" Then it sort of seems to set up this atmosphere and relationship where more Agile-y context seems to set up more of a teamwork. Like, "Hey, we're all on the same team. We're going to get this thing done together. Let's figure out how we can make this happen."

Kristin

Yes. That's definitely the style of relationship that you want to set up. I think that people, particularly technical people, developers and user experience people, a lot of times really, really like the idea of Agile. People who are more visual, designers, graphic designers, project managers tend to be a little bit more suspect of it. Because they're afraid that they're going to be losing some kind of control or quality or something like that. I don't view it, personally, as one is better than the other. Which is probably why I'm a pretty big advocate of blending the two. I really think of it as projects have differences and project teams have differences and clients have differences and it's about sussing out the landscape of the particular opportunity in front of you and choosing what's going to work best for that particular opportunity in terms of coming up with the best end result. If you had asked me that question five years ago, I would have said waterfall is where it's at and it's the way to go and our waterfall process is really great because it provides enough flexibility that we can get what we need done, done within the time frame. The only problem I saw with it was that it was as very, very hard to predictably define a scope against a budget. I used to ay all the time, if we could just contract this discovery and planning stages with an estimated bid for production and deployment, then we could adjust at the end of discovery and planning, that would be the ideal way to go for both of us.We can do some prototyping during planning, we can really figure this out. Then if there's a difference in understanding at that point then we can adjust. There are are two ways to adjust. One is to adjust the scope to meet the budget and timeline. The other is to adjust the budget and timeline to meet the scope. It's pretty simple, black and white math from a logical perspective, but we're dealing with people here, we're not dealing with logic. We're also dealing with company policies, also, not logic. [Laughs] It never really worked. The few times that I did sell that through, we also had the same problem where they ended up not actually going through with the whole project. That sounds like a really great idea but it didn't really work. What we try to do now is definitely more of a blend of the two. But it's really all about the particular client and whether or not they're willing to do what it takes to successfully build an Agile project.

Jen

You just launched a new project with the School of Visual Arts, where you reworked their website for at least the second time. Maybe you've been working with them even longer. We were talking a little bit before we started recording and you were saying that you switched your approach with them. You'd been using more of a waterfall and you switched to more of an Agile-y, Agile process. You want to talk about some of that and how it made more sense to go with a different approach?

Kristin

School of Visual Arts has been a client of Funny Garbage for a decade. We have built multiple websites for them over that time. We launched in 2012 a really new, modern website and backend system for them built on a PHP open-source platform called Symfony. It's a long, complicated story but for reasons I won't get into, we didn't end up having that site be designed as a responsive site. At the time, they just weren't ready, et cetera, et cetera. So we launched a fixed-width site. We took into account tablet screen, horizontal aspect ratio, things like that, and we launched a really, really beautiful site for them. After we launched the site, we kept having these conversations about them about, "the mobile app, the mobile app, what are we going to do with the mobile app? What are we going to do with the mobile app?" Everything they were asking for was really essentially a duplicate of what was on the website. I kept saying to them, "You should just let us go back and make your website responsive so it works on the phone." The audience for schoolofvisualarts.edu is students. But primarily prospective students and their parents. That's the biggest audience for that website. A lot of those students and prospective parents are actually overseas. They have a large contingency of people coming from Korea and that part of the world. Those folks are really heavily into web use on the phone, particularly Androids. They were having a big problem because the sva.edu site is really about marketing to prospective students, letting them know all of the wonderful, amazing things that the school does, all of the different degrees they can get, all of the different amazing teachers that they have there. It wasn't really working. So we convinced them. It's an unusual project, right? But unusual projects happen. So we convinced them that what we wanted to do was to take the site that we had already designed and already built the backend for and turn that site into a responsive site. Which is pretty challenging, to take a fixed-width designed site and turn it into a responsive site. But it's definitely doable. Because this was much more of a technology implementation project, we decided that it would make sense to work in a more Agile way. Obviously School of Visual Arts is a design school and they're very, very, very attuned to visual design and the way things lay out and the way things look. It's extremely important to every client, even more so with the School of Visual Arts. We were working on getting this contract signed and then they decided, in addition to making the site responsive, we actually want you to build a whole new backend based on Symfony 2. So we took a Symfony 1 backend... what we originally thought was an upgrade, but it really was a rebuild, because Symfony 2 is significantly different than Symfony 1. We were able to keep the backend user experience of the content management system the same but we had to basically change all the plumbing out and rebuild this whole backend system. So we changed the backend technology and we changed the front end templates to be responsive simultaneously. Pretty much a tech implementation project. Again, made a lot of sense to really try to follow an Agile approach. They liked that idea and signed on for it. As you mentioned, we'd be working with them for a long time. Every project we'd ever done before was a waterfall methodology and we were able to design these picture-perfect PSDs of these beautiful pages where everything was completely wonderfully aligned and there were no challenges at all whatsoever with layout. Taking that style of design, taking that approach in terms of the project management approach in terms of waterfall, and turning it into a responsive site done with a new technical backend, done using an Agile process, was a huge change in how we worked together as companies. There were some great things that came out it and there were a lot of challenges, a lot of learnings that came out of it as well. We actually launched the site on Monday. I would love for you guys to all go check it out. It's sva.edu. We ended up getting there and we ended up getting a site that's really beautiful, works well, works on all the different viewports. It's not exactly the site that we would have designed had we started out from scratch saying, "We're going to build this responsive site for you." But there's definitely something in this idea of Agile methodology and responsive web design that works really well. Now, they're not the same thing. They're two different things, obviously. But I think this movement into responsive web design is really helping propel all of us forward in getting our clients on board with working in this more Agile way.

Jen

People have been talking about this a lot. It's come up a lot on the show. It came up a lot at Artifact Conference that we were both at. There's something about the waterfall methodology, this kind of pre-planning. Let's sit down and pre=plan everything so there are no unknowns. We'll get you to sign off on everything and then we'll bid exactly how much that's going to cost and you're going to know exactly how much it's going to cost you before you say yes and write a check. That depends on, like you said, these beautifully rendered Photoshop documents. Photographs of the future website. Responsive is just not... it's just a waste of time and money and resources to have people sit down and draw eight Photoshop documents for each web page. This is what it looks like in mobile, this is what it looks like on a bigger phone, this is what it looks like on a small tablet, this is what it looks like on a medium tablet, this is what it looks like on a sideways tablet. It's just not reasonable. It's much better, it makes much more sense to use other kinds of tools, Use Photoshop along the way but not for this kind of big reveal and not for this big "sign here, now we're done planning" kind of thing. Let's come up with all of these different tools and these different methods. Let's not have it be designers in a room with content people. Designers who don't know anything about how the technology works. Coming at it as if it were print from a graphic design perspective. Having private meetings and making a whole lot of decisions and then sending it to the developers with no information about the details of the design, with no interactivity, no movement, no motion, nothing that's specific to the web, pretending that it's print. Then when the developers have questions and they have needs and they realize that there are certain things that weren't planned, they're not allowed to call the other people that they've never met, they've never been in a meeting together. There's just so many bazillion reason why that doesn't work. Probably every episode of The Wen Ahead is another reason why [laughs] that doesn't actually work so well anymore. So you end up with the desire, coming from that side, of, let's have the designers and the developers collaborate. Let's have the developers come to the first meeting. Let's not do a whole bunch of planning and then go to code. Let's do a little bit of planning and start coding and do a little bit more planning and then change the code and keep iterating back and forth and back and forth and then, oh look, we've got this thing that we really, really like. It's all coded up. We think we like this. But, oh yeah, that's not the real code. That's the design, practice code. Now we're going to re-code it. It's a lot more back and forth. Much more messy. Much more human, much more face-to-face, much more like, let's collaborate on this rather than let's send each other boxes of finished work.

Kristin

Yeah, absolutely. You made a a couple of really great points there. The first of which is that the move into responsive is really giving rocket propulsion to the move into Agile development, or as I like to say, Agile-ish development. Because it's almost necessary. What's very cool about responsive web design is that it's actually the first time, and what's very cool about the Agile approach, is that, for the first time, we're actually really designing and thinking about creating websites in the technology that they're actually created in. As you mentioned, we used to design websites using print metaphors. We're design them on paper and then we translated them into the technology of the web. Now we're taking the technology of the web and using that as our design process. It really makes a big difference. A lot of agencies had the wall of the UX and the design people were gods and then they would just throw it over the wall to the technical people and then all craziness would break loose. Funny Garbage was never like that. Funny Garbage has always had technology people in the process from the very beginning. We've always had our technology people in the very first meeting and all the brainstorming and planning sessions. But there's still a big difference between having a technology person in the room, thinking and talking, to having a technology person simultaneously working with a visual designer or user experience person, creating code from the first week of the project. There's a monumental leap forward in effectiveness, in creativity, in output in terms of what can actually be accomplished. It is about communication and it is about human messiness because human messiness is the reality. As much as waterfall tried to pretend that everything was buttoned down, and that was really going to work out just fine for everybody, and it was lower risk, at the end of the day it was just as messy as anything else it was just about delaying the messiness to the end of the project where everyone was really upset.

Jen

Right. When the launch date has slipped for the 16th time and you're way, way, way over budget.

Kristin

Yeah. And we always prided ourselves, "We;re really great at hitting launch deadlines and we're really great about making it happen within that time frame." But now we go back and analyze, "How'd the project go?" I would find out, time and time again, god, the client just loved us and loved us and loved us during discovery. They were just our best friends through planning. And then all of the sudden, when we got into technology development, they started getting really upset about things because problems started cropping up, and "Oh, that's work the way we thought it was going to work." Their perceptions was, that's because you failed and you're bad at your jobs. As opposed that, "That was a bad process and we shouldn't have been doing it that way in the first place." We would end up at the end of the project with the client being really mad and upset at us, and frankly thinking we did a terrible job for them. Which was pretty much never the truth or rarely the truth. I'm not saying we haven't made mistakes, because we certainly have. But we would always rectify them. We would always stand by our work and make sure we got it delivered and got it launched on time and we would do what it took to add other developers and calm them down and spend a couple of panicked months dealing with all of those problems. We ended up spending more money than we needed to. Working really hard and getting no credit for it. Bending over backwards and then having the client not be super-satisfied with out work. I'm not saying every situation was like that. But it was a pretty common scenario. Whereas, with Agile, it allows you to deal with problems throughout the process. Problems don't go away but it's not just a big firestorm of problems all at the end of the project where everyone gets really upset and that's all they remember.

Jen

You said a bit before that by having a developer or technician of some kind in the room for the first week coding things right away has allowed for some really remarkable things to happen that wouldn't have happened otherwise. Do you have some examples of that or some more you could say about that?

Kristin

Sure. One of the things that I always say to clients is, pretty much anybody can have a good idea. They can talk a good idea. Sometimes they can even put a good idea on paper. But at the end of the day what separates somebody who's successful and sees something through in this world is actually the quality of the execution. If we're talking, talking, talking, planning, planning, planning, papering, papering, papering, for the first good half of the project and then the development doesn't start until the second half, that sort of magic of the execution becomes a real factor. We've always prided ourselves on our execution being what separates us out. We do a great job at the beginning because we understand the execution. But it's rigid, it's not a flexible process. It doesn't allow for the website or the app or the game or whatever it is to really breathe and grow and evolve. The idea of having the actual coding and the testing from the very beginning really sets up that ability to create something amazing. We tend to do a lot of internal projects that are R&D, passion projects of various staff members, ways to take on a learn new technology. Proof of concept to show things to clients to get them to hire us to do the same thing for money. I think those are probably some of our best examples of being able to create some really cool, special stuff. Because the devil's really in the details. If you can work towards getting that minimum viable product up and running as quickly as possible, then you can start to see it in action. You can layer beautiful interface design personality on it. You can see, this would be a really cool place to add this little piece of extra functionality that makes a big difference in this just amazing user experience versus, oh, ok, this works. It works and it's alright but it's not this magical intuitive experience. Which is what you can get when you're actually live coding, changing things around. You have a developer and you have a UX designer and a visual designer right there working side-by-side and creating these things as a team.

Jen

Yeah. I think especially with the new technology that we talk about a lot on the show. A lot of people just don't know about it yet so they're not imagining. Designer's even, and clients especially, they don't know that you can do this and that with audio. Or that you can have a live open connection between multiple people through a web browser. You can have the website listening using the built-in microphone on the device and respond to what is being heard by the computer itself. Especially anything like that. I think until the technology is used more and more and more, people are seeing how their competition is using it, they're not imagining what's possible. By having the developer in the room, by having a more team, a range of talent rather than a team that's focused on one particular piece of the puzzle, that those kinds of things are more likely to happen.

Kristin

Yeah, absolutely. I think the other piece that I really want to highlight is that because we were able to use this more Agile approach, the client was able to see things really, really early on. Now, they weren't really that comfortable doing it, to be honest, and it was a bit of a leap of faith and bit of, "How do we get them to look at this and see the right things instead of looking at it and seeing all of the quote-unquote mistakes?" I.E. The things that we haven;t gotten to yet. I completely understand where they're coming from. These are some of the best designers in the world and they run a division that does print design as well as digital design, so they're really about the most beautiful visual presentation you can possibly experience. It was hard and it was really challenging for them to say, "Ok, you're asking me to look at global navigation in many different formats simultaneously and to focus on that piece of it while the primary grid of the display of all the images of what's happening around campus is a complete disaster and completely broken and not displaying right at all. I can't separate these two, it's really hard." Which we totally get. But the fact that we really, really got them there to do it, they were able to give us really good input and really good design feedback around things that we hadn't necessarily anticipated, that we definitely hadn't anticipated when we did the contract. It makes a difference at the end of the day. We did some crazy stuff that we never thought we would do. It may not sound crazy, but fonts. We changed fonts. Once we say it in all the different viewports. Which was not part of the original scope of the project. It was, make it responsive, not play around with fonts and play around with type sizes and things like that. But at the end of the day, in order to make a beautiful responsive site that looks and feels good on all these different devices in all these different viewports, we had to change some of the fonts around. We had to change the point size and the boldness and things like that in order to make an experience that really worked beautifully across all of these different views. Having them there to talk through that, as anxious as they were at certain points, the end product really came together very beautifully because of that input from the client from the get-go.

Jen

How did you set a contract with them? How was it different this time around with SVA doing Agile instead of waterfall?

Kristin

It's kind of interesting because it didn't feel as... because the site already existed and all of the content planning had already been done and all of the navigation structure already existed, it was a slightly different approach than what we would typically do. Where we would do a big detailed list of all the different features and functionality we're anticipating building. We already knew what that was. The challenges were this huge backend move from Symfony 1 to Symfony 2 which was really all about just this very, very deep and, you know, frankly, ground-up rebuild of the technology. It was the same team who had built the first version of the CMS in Symfony 1, which was fantastic and that really helped us out. I think that part of the process worked very well with the client. This client has a really great technology team in house. That was the other thing. That we had the whole technology team from the client side involved in the project from the very beginning. Learning Symfony 2 as we were developing it. Involved in regular scrum meetings. Involved in looking at the functionality and technology on the backend from the get-go, not waiting until some QA period to get in there and finally start playing around. That was really, really helpful. In terms of the contract, the contract was much lighter and leaner than a typical waterfall project contract would be because we weren't having to go in and list all of the different feature sets. I actually looked back at the contract this week and in hindsight I saw a lot of really grey area in there where I didn't describe things very well and I didn't define things very well in terms of how we were going to go about doing it. Because essentially it's a huge shift from contracting features and functionality to contracting process. What I will do going forward is really spend a lot more time detailing the process of exactly how it's going to work. One of the challenges was getting the client's time on a regular basis, to be in all these meetings and spend the time looking at the work as we were producing it. We mentioned that upfront but we didn't get them to truly understand what that was going to look like. That was a bit of a failing because they didn't have the time. They had other tasks and other jobs to do. We had to really focus on constantly pulling them in and constantly getting them to look at stuff and constantly, "But you've got to be at this meeting. This is not optional. If you don't come the whole process is going to fall apart." I would say in hindsight that the new contracts I do for this type of work are going to be much more focused on roles and responsibilities and processes and how we're going to work together as an integrated team.

Jen

So a typical contract in the past would've been, what,a list of exactly what features that the new project would have, even down to... would you do a lot o budgets where you would try to estimate out exactly how many... hours or, each one of these things is going to cost you this amount of money?

Kristin

Yeah. Oh my god. The Excel sheets were out of control. Where we had five tabs and here's all the front-facing technology, here's all the back-facing technology, here's all the template types, here's all the primary modules, and how many hours are each of these going to be and then we'd add them all up and then we'd say, ok, let's put 20% pad on top of that and then we'll do our QA separately. The philosophy of how we were approaching it was sound. The amount of energy and time that we put into sussing it out was massive and frankly, always inaccurate. It was always this conversation of producers being like, "Oh my god, the technology people, they're so bad at estimating time. What's wrong with them?" The technology people being, basically, "Are you out of your mind? How can you ask me how long this is going to take me to do? We're not punching license plates here. You say 'video module' like that means one thing. We all know there's huge differences between one website's video module and another." And then we'd be wrong and then we would have no leg to stand on. Because we spent all this time estimating it and then we came up with this contract with this quote-unquote detailed list of features and functionality. Which is never detailed. It's actually high-level, as detailed as you think it is. And then we would bid our project and we'd be wrong and we wouldn't really have any recourse. It was very stressful. People were pushed to the limit to get it done on time and hopefully on budget or close to budget so we didn't kill ourselves.

Jen

yeah, it seems like that kind of world does set up such a weird atmosphere. A relationship where something like video. Ok, you're going to have a video on the website. You've got 10 hours to build that because we said that's going to be 10 hours.

Kristin

Right. "Well, that's not my fault that you didn't understand my business requirements and what they video player really needed to be." That's the conversation. The client comes in and they're not trying to be adversarial. They're not trying to be jerks.

Jen

Right. Exactly.

Kristin

Most clients are not trying to take advantage of you. They're basically like, "This is how much money I have and my job is to get you to do as much as possible for as little money as you can and to make sure that you make me look good to my boss." At the end of the day, that's what motivates almost every client. That they have to be successful. Unfortunately, success is often defined by quantity and not quality. I think that the waterfall approach is very much a definition of the quantity of work and the Agile definition is much more focused on the quality of work.

Jen

What is a contract in the new world? What does it tend to look like? Is it a list of weeks? Like, you're going to hire us for this many weeks and this many moneys? And we'll just get done as much work as we can in that time? Or is it, I mean, you said it's a description of the process. Are you writing out, "Hey, we do four phases. These are the phases we're going to go through." Or...?

Kristin

We're in a transition state for how we contract and, frankly, for what our process is. I keep re-saying that we use a waterfall-ish methodology because we still have the framework, typically...

Jen

Agile-ish, you meant.

Kristin

Yes, Agile-ish. With the School of Visual Arts we actually really did have a full, responsive approach outlined. Typically with our clients we would have sort of a waterfall framework where we do some discovery and planning upfront but we start, we call it, "prototype". Which is essentially beginning technology production from the get-go. So we're actually building during discovery and planning but we're more in a prototype-y kind of phase as opposed to a full-on, daily scrum meeting kind of phase. Then we take a lot of those really cool things that comes out of Agile with daily scrums and we use Pivotal Tracker as our software, which is fantastic to track tasks sand to figure out what's in the backlog and what the priorities are and all of that kind of stuff. And really try to get the client involved at that level. Most of them have a bit of a waterfall framework still involved and we just try to push them into the development phase much sooner. In terms of a pure Agile contract, it really is much more about defining not every single feature and functionality but the minimum viable product and then selling them on the process of, here's what we believe the sprints will look like for this minimum viable product. And then we're going to hold back 20% of your overall budget to then evolve past that minimum viable product rather. And then hopefully, even save another 10% of that budget or so for post-launch adjustments. Getting them to understand that when you launch a website, it's not like publishing a book or a record or something of that nature in traditional media. It's publishing something that's a living, breathing thing, that from the second you launch it, should be changing, should be evolving, not just from a content level but from an interface level, from a functionality level, as you live with it, you evolve it over time and that's what ends up making a great website. It's really setting up the contracts to be structured in a way that's not so much about... there's definitely detail around what the client's going to get. Because they're not going to just walk into a pure, "Sure, we'll see what we get at the end of the day." They need to know what that minimum viable product is that they're buying. And then getting them to understand the process of, we're going to get here as quickly as possible. Then we're going to flesh it out. Then we're going to add whatever's exciting, user-interface-wise or new-feature-wise or whatever we can invent that comes out of developing the project. The idea will always be better than something that we preconceived on paper upfront. If it's conceived while the website's being birthed out there to the world and being developed. If that makes sense. [Laughs]

Jen

yeah. It seems that a lot of shops, a lot of people, are being very creative in their contracts these days. Make it up as they go. Make up, ok, I've got a new possible client, so let me come up with a new idea of how to do a contract.

Kristin

Yeah.

Jen

While we're all in this transition, while the whole industry is in this transition, it seems like from what I hear in talking to people, is there's this effort to define expectations and to define, "Ok, I'm a person and I have these talents." Or, "We're a company, we're a team, we have these talents, these things that we can do for you. And this is how much it's going to cost you." Whether it's time and materials kind of contract where it's exact hours or whether it's chunks. Like, you can get us for a month, this is how much it will cost for a month. It's almost as if there's a circular pattern to it. Let's go ahead and contract this next piece and let's define expectations on both sides, how we expect this to go and let's just get started and we'll go ahead. Maybe we'll have another contract later because that went really well and we want to keep going together and we'll do another contract after that. Then, oh, look, you have four other websites that you realized you really should do next. Oh, you still like us. Ok, let's write another contract and get started on that work. That's what I'm starting to see. It's more like a long-term relationship that ends up happening with multiple promises made along the way and the contracts become a kind of, let's clearly talk about what we're expecting and document those expectations and lets make promises and we'll document those promises. But it's less of a... it's not as much of a thing that I think bigger, sometimes, companies, more traditional, need. I don't even know what word to use. We're going to give you a bid. You're going to write an RFP. We're never going to meet. We're going give you a bid and you're going to take our bid and you're going to take 10 other people's bids and 10 other company's bids and you're going to line them all up and you're going to say, "Look, this one is 14% cheaper than that one and lets go with this one." That kind of thing doesn't really... I don't even know what I'm saying. But somewhere in there is it. [Laughs]

Kristin

Oh, absolutely. That's the whole other topic. The whole competitive bid process and how that absolutely does not work. My favorite author, Blair Enns, has this great book called The Win Without Pitching Manifesto. Which I highly recommend you all check out. It's my Bible. But the thing is, you're right, Jen. This whole idea of this very fixed price, fixed bid, fixed scope project, that a client puts out an RFP and then accesses five to 10 different company's responses is a complete fallacy. None of those companies is going to be able to deliver exactly on what they put in that contract. Some companies out there will even underbid it intentionally, knowing that they're going to up charge you later in order to win the project and get that, "I'm 14% cheaper. But not really." Nine times out of 10, the purchaser or the client doesn't actually have the training or the ability to differentiate between the different contracts. So they end up basically going with the one that's the cheapest or the one that has the best, most awesome, coolest, Mad Man-esque sales team to convince them that they're so wonderful. Typically companies that have those amazing sales team spend all their money on sales and don't actually have amazing follow through. So. You know. And then they get unhappy and then they come back to Funny Garbage and say, "We spent most of our budget but we still need it. Can you do it for us for half the budget?" Or other companies like us. [Laughs]

Jen

I think we've all had projects like that. Cleaning up other people's messes. It's so sad. Like, wow, you spent all that money and now you just don't have it anymore. But you still have a great project.

Kristin

Exactly. Technology really intimidates people. This is the thing. Change. People don't like change. It's very against human nature because change introduces fear, anxiety, there's these structures that have been set up for a long time. This is how you succeed, this is how you make your life good, this is how you take care of yourself and your family, right? It's all very understandable and human. But the thing is, is that, things are changing very, very, very rapidly, right? How do we re-contextualize this and how do we communicate to our clients that it's changing rapidly. We're figuring it out as well. We are experts, so you can trust us. But we're here to basically work with you through this process and actually not pretend like we know exactly what it is upfront. But that basically be very honest and say, if we knew exactly what it was upfront, that's a very boring, safe approach. We're building something that's been done before and it's probably, at the end of the day, not what you really want. But how do we address setting up a process that will keep the human-ness, the human anxiety and the human fear of change, comforted and allow us the freedom to create the absolute best user experience and the best feature set for the website throughout the process. It's really about understanding how to set up a good partnership with your client. Getting them to understand what that process is and that they're actually more empowered in this process of Agile development than they might be in a more waterfall process. That they're not going to be trying to stand over us and beat us wit ha whip and we're not going to be standing on our side saying "no" or throwing change orders their way. But that's it's actually a very empowered communication where throughout the process they will able to adjust course or pivot or decide, "No, it's not a soccer field, it's actually a football field because something really radical changed and that's ok." Allowing the team to steer and pivot together as opposed to working with cross purposes. That's really what Agile brings that waterfall doesn't offer.

Jen

But how do you deal with the fact they need to know how much it's going to cost? "How much is it going to cost?"

Kristin

I believe, in my business, they will always need to know how much they cost. Because they get their budgets a year in advance and this is how much you have and you have to do X amount of websites, X amount of games, X amount of mobile apps, and this is the amount of money you have to spend. Whoever does the best job at the end of the year and spends less money than they were allocated and delivers more products than they allocated gets a big raise. And that's how the corporate structure is set up. You can hate that all day long but it's probably not going to change it. That's probably a reality that will continue to exist for quite awhile. What we do is we do this blend of Agile and waterfall and we do a blend of, you know, they're going to still come at me with the RFP with the pre-set idea of what the features and functionality is. We're going to say, great. We get that. Here's how we're going to go about approaching your project. Here's how long we think it's going to take. We're going to divide these things up into different sprints. We're going to be very clear about what our expectation is of you and what your role is in our process. That's a part of the contract. Through the process, we're going to have regular conversations about how that's going, what's working, what's not working. We're going to contract is in a way that it will end at this point and here's the plan of action after that." The School of Visual Arts is really great because they have this in-house technology team that does a really good job. With the School of Visual Arts, we said, "Your team will be involved deeply in the project from day one. In fact, they're actually going to take pieces of the production and implement them as we're developing the rest of the backend." So they really know what's going on. We had a fixed timeframe. We went over that timeframe. The client understood that we were going over that timeframe. Some of that was miscalculations on our end, some of it was miscalculations on their end in terms of the amount of time they could spend with us. At the end of the day, we worked it out and we evolved the timeframe of the project and we were able to work through all of the different essential elements of the projects and ge tit delivered and launched. Now, moving forward, things that we weren't able to attack and deal with during the project, either their team can approach it or they can come back to us and we can do an ongoing, we call them "maintenance" contracts. It's not perfect. It's probably never going to be perfect. It's really about setting up the best structure possible. Educating people as much as you can from the get-go and constantly reassuring them throughout the process and dealing with problems as they arise.

Jen

It also sounds like just being willing to assert what you think is going to be best for your clients and for the projects, in order to have successful projects. Even if asserting those ideas about how to structure the contract, how to structure the project, how to manage things, are going against how they wish the world were. That they want something that's more clear and more safe and it's really just about being honest and saying, "Hey, that is not going to work. We've tried that. We've seen other people try that. It's not going to work. We want to tell you right upfront. This is how it would be best. If you hire us, we're going to do it this way because it's going to give you the best results." And then sticking to that and making that work. Being flexible with that but not falling under the illusion that we can just predict everything and give them a fixed bid and they can compare apples to apples to apples and pick the cheapest apples.

Kristin

Exactly. It's also a good way to weed out clients that are going to be incredibly problematic at the end of the day anyway. Because you don't want to work with a client that doesn't trust you. You're not going to work with a client that challenges your expertise. It's very tempting to want to take every project that's offered. We all have bills to pay, we all want to bring in as much as we can. But it weeds out and self-selects client relationships that work well. And those clients will come back to you over and over again because they respect the fact that you gave them the truth and that you gave them the truth upfront and that you delivered for them. They can't expect a project to go perfectly perfect with no challenges, no problems, no whoops, somebody didn't think about it or somebody didn't get it or somebody didn't communicate it. That's part of production and that's not a bad thing. That's just actually how serendipitous, interesting things typically come out the projects that we do because the unexpected happens. Instead of fearing the unexpected and pretending like you don't have to have the hard conversations upfront, it's just about embracing it and looking at it from a different viewpoint of, these are all really good opportunities to evolve what we're doing for you and to make the right decisions about what we're doing for you and focus on the priorities instead of just ticking off a list of things that you thought you needed six months ago.

Jen

It's interesting to me the way you described the pain all being at the end in more of a waterfall process. It's interesting to think about it. Like, there's going to be a certain amount of crazy and pain and disappointment and, "We thought it was going to be like this and it turned out it's not like that, it's completely this other." But to spread that out through the whole project. [Laughs] Including right up front from the beginning and to include the client in finding solutions along the way and be able to say, three weeks in, "Hey, you know what? We can already tell we're off target from where we thought we were going to be. What do you want to do about that? Let's go ahead and change scope." Or, "Let's go ahead and focus on something else. We can fix this now or we can wait." It just seems the more traditional way, the waterfall way, just pushes all the pain to the end and doesn't really prevent any of it. It just changes when it happens.

Kristin

Right. There's going to be a certain amount of pain and there's going to be a certain amount of really happy, wonderful moments in the lifespan of any project. By putting all the good stuff up front and all the bad stuff at the end, you end the project on a bad note. If you spread it out throughout, then it's much more even-keeled. I think the other thing that you said, and I like the language you were using about, "What are we going to do? How do we solve it? Let's decide this." It's really about having one cohesive team as opposed to a client team and a project, you know, agency team. That makes all the difference in the world. If your client walks away and thinks, "Wow. I just designed this website and I did the most amazing job ever." That's the best thing in the world. Because of course they're going to come back and hire you again. You don't want to be like, "My vendor did an ok job." That's the worst thing that you could possibly get from a client relationship once you finish up a project.

Jen

Yeah. Well, thank you so much for being on the show today to come talk about all this stuff.

Kristin

Yeah, absolutely, thanks for having me. Would love to continue the conversation another time.

Jen

People should check out sva.edu and they should check out, it's funnygarbage.com is your company. And you are on Twitter, @krs10ellington. People can follow you. Right?

Kristin

Absolutely.

Jen

People should find you.

Kristin

That's probably the best place. And you can also check out the Funny Garbage Facebook page. We have a funny Tumblr page. Funnyfunnygarbage. [Both laugh] We publish a lot of goofy, popculture-y kind of content. But in terms of chatting with me directly, it's Twitter @krs10ellington.

Jen

Nice. And the show notes today are at 5by5.tv/webahead/62. Where people can find links to all these things if you're not writing them down or don't know how to spell things. And I want to say thank you, again, so much to FreshBooks for sponsoring today's show. People can follow me on Twitter @jensimmons or the show itself @thewebahead on Twitter. That's it until next week. Thanks for listening.