Agility vs Agile: When the Best Approach is Waterfall

Emily Lonigro Boylan

Transcript      Links

We love the idea of Agile, but we hated a lot about it practice. When you're juggling a bunch of different client work, adhering to a strict methodology added bloat, time, people, and process to something that could have been a lot simpler. In an effort to make tech products simpler, we now use a more flexible model taking cues from Agile, all in the name of the most efficient, most impactful product.

Being rigid with in a system, even if the system itself is intended to be flexible, can create unnecessary waste in terms of technology, time, and effort. In an attempt to be lean and efficient at all times, we've developed methods to prioritize efficiency rather than a set of guidelines.

This talk outlines that process, where we make decisions, where we stop and reflect, and our guiding set of principles that can be applied to any project.

Being rigid with in a system, even if the system itself is intended to be flexible, can create unnecessary waste in terms of technology, time, and effort. In an attempt to be lean and efficient at all times, we've developed methods to prioritize efficiency rather than a set of guidelines.

Bio

In 2004, Emily founded UX agency LimeRed Studio with a plan to prioritize high-quality design, user experience, and meaningful social impact. Lime Red is now the nation’s only WBE certified B Corp UX agency. Over the last 12 years Emily has built this business into a reputable presence with national-scope clients focused on doing work that has socially responsible intentions.

Her experiential spectrum includes design, business development, user experience, writing, marketing, and strategy in both online and offline programs for multinational corporations, nonprofits, universities, boutique businesses, and prestigious consumer brands. Today, Lime Red’s focus is creating stunning creative pieces for nonprofits, conscious companies, and educational organizations to do work that makes people’s lives better.

She is Vice President of the Board of nonprofit MOM+BABY where she has developed conferences and events, Mom Congress, and is developing the Women Supporting Women movement. Emily is also the co-founder of ImpactX Labs, an accelerator for solving social problems with human-centered design and collaboration. She's a member of the Social Enterprise Alliance, member of Ms.Tech’s Executive Circle, and active in NTEN. She’s run accelerators for nonprofits and is a mentor for other women in business. She’s a published writer and teaches workshops on business development, information architecture, UX design, branding, and content strategy. Emily is also regular speaker and panelist at national and regional conferences.

She’s a mom, activist, small business owner, designer, and activator.

LimeRed Studio
Facebook
Instagram
Medium
Twitter

Transcript

Thank you for having me. I can't believe I'm following Dr. Mann. I hope you all get out of this what we got out of that. That was amazing. Thank you so much for having me today.

You heard about me and what I do. My agency is a UX agency. We do a lot of testing, prototyping, building, testing, messaging, stuff like that. I don't want to talk too much about what we do. I want to talk about what we're going to talk about, because it's good to know what you're getting into. I'm not totally sure who's in the room. I know we have some engineers and some designers and some other roles in here. Some owners, some thinkers. So I'm really quickly going to walk through Agile Method, talking a little bit about scrum, talk a little bit about waterfall, because I know they're all different things. I'm going to interchain them and all of the developers in the room are going to get mad at me. I'm going to talk about how we do our work and what we've screwed up and what we've learned from and how we do it better. The name of the game at our studio is all about efficiency and the goals. I'm going to talk a little bit about how we typically run a sprint using the Agile Method. Particularly, how we do it based on the conditions at our agency. I'm going to talk about the pros and cons of running this that we've found out over the last four years of doing it. The title of this is what happened when we mixed in waterfall. Sometimes we have switched back to waterfall, and I'll tell you what conditions have to exist in order to do that, and why we did it, and how it worked out, and how we think about our work. Because it's very, very different than we used to think about it. We'll talk about the conditions that had to exist in order for us to do this work. Then talk a little bit about how we redefined Agile for ourselves.

ur spirit animal at LimeRed is Yoda. We typically throw ourselves into a process and do everything we can to do it. We don't dip our toes in first. We fling ourselves full body into the pond. There's do or do not. There is no try. Here is the story of our not trying and doing over the last four years.

For people who don't know what Agile Method—capital "A", capital "M"—are, these are the six principles of that. Define a measurable goal, which makes a lot of sense. Everyone on the team owns the problem. It's not just a developer problem or a design problem or an owner's problem or a researcher's problem, it's everyone's hands in all the time. You make small steps with visible impact, which is probably my favorite thing of Agile. You're making these little iterative changes and launching everything, launching as you go. You're not trying to make a big dog and pony show like you would with waterfall, which I'll get into in a second. You're going to validate and test everything that you do all the time. I'll talk at the end about how we look at that differently now. Measure success and iterate.

We started out being a design agency then we went into being a developer agency. When we started, this is what we did. We collected the requirements, we decided what we were going to do, we designed it, we sent it to a developer or we built it ourselves, we test and QA and spend a moth doing that, and then we maintain it. We sell somebody a maintenance program. Which is really the worst way ever to do anything and it pisses everyone off. Unless you did what we did and mixed them in together.

This is a picture of our actual current wall. If you're not familiar with scrum or sprinting, what we do is, based on these principles of the Agile Method, we run scrum. We used to run them in two week iterations. We figured out that wasn't working for us so we stretched them out to three weeks. In the very beginning, what you do is, you define how you're going to be successful. It's called success criteria. Based on a user story—it's all user-centric—how will we know when we're done? How will we know when we've built, designed, wireframed, or launched enough to get done? That's a group-facilitated meeting that everyone attends. It's a big, huge, long thing. it takes us about two and a half hours. It's a seven person meeting plus clients. In this instance, it's Monday. Then we go into wireframing. We have a little popup of, "Are we doing this right? Do we have all of the requirements? Does anything need to be adjusted? Are we going to be able to complete this within scope?" Then we do a wireframe review with our client. We're an agency, so we have clients. We're not just building a piece of software. Then we structure and style everything and review everything. During this time, we're QAing all of the front-end. Then we build and style all of the back-end. We review it. Then we review and test. During this revision testing/QA bar at the bottom is a bunch of training. We're training our whole team on the system. We're also training our client on how to enter content or do the things that they would do in their job everyday. At the end of it we have a retro, which is a meeting where you look at, historically, what went well? What didn't do well? What could we improve?

This is basically the skeletal structure of how we've been building everything we've been building for the last three or four years. A lot of times when we read about Agile, the problem we have with it is that it's very much built for a product team who's building one product. But we have about 10-12 clients at any time and we're building about four to five to six builds at any time. We have a pretty small team of six people and about six dev freelancers and some dev partners. We also use Slack, Teamwork, Pivotal tracker, and Google Docs to manage all of this. This is a picture of our whiteboard with all of our jobs and sprints staggered out. So we've been doing this since 2003 in the name of being a very efficient, energy-efficient, streamlined, B Corp, UX agency that builds really smart technology. Because of the guiding principles of being a B Corp. We're very much interested in conserving energy. We're big fans of Tim Frick and MightyBytes, who are down the street from us. We absolutely adore them. We read everything they do. Shout out to Tim, hi Tim. We're looking to use the most predictable, most beneficial, most impactful system that we can. Looking at Agile, we were like, theoretically, this is definitely the thing that we should be doing.

Let me give you a little history of when we started implementing this Agile or scum method. We went from very much a designer-centric process to a very developer-centric process. Which was so good to do because we all started to weigh our roles differently and look at each other as an interconnected team. It wasn't one person handing something else off to another person. In terms of just the culture of the organization, everything shifted. It shifted from the design lead to a dev lead. Which is really interesting and really different to see how my team moved. Lately, in the last year and a half, we've shifted it from being developer-centric to being user-centric. Even in the last six months everything shifted. We went form being user-centric to being business and team-centric. When we're looking at the Agile Method overall, we're not only applying it to our business, but to how we operate as a team, how we interact with clients, and how we develop products for them. It's been a definite shift and it's been a lot more efficient.

One of the biggest things that happened when we shifted was we had to question the idea of our roles in the team and how we operate. Which was a really eye-opening experience for us to do. This is a typical team: I have a project manager, front-end person, UX researcher, back-end, owner—owner is me—strategy lead, and creative/UX lead. When we're running scrum, everyone comes with their specific job role or specific tasks that they have to do. A lot of times it's competitive, or it's not totally clear what part of that Agile Method, since everyone owns the problem, it wasn't quite clear who owns what part of that problem. We all had our very specific job titles but UX researcher and strategy would overlap. Creative would overlap with front-end all the time. Front-end would overlap with back-end. I'm overseeing the whole thing and harping on my PM to get this project done on time.

We realized we had to clarify who we advocate for. We redefined our roles. The project manager is the advocate of the project and the budget. The front-end, Laura, my front-end developer, is the advocate of the quality of the project or the product. You can read the rest of them. My job is to advocate for the relationship between my staff and between my company and our client companies. I'm going to make decisions based on the thing that I advocate for more than getting all upset about the project and budget and timeline or something else that's going on. That's really Annie's job as the project manager to advocate for the project and budget. Interestingly, a lot of times, some of these are at odds with each other. But we come to a problem and approach it from a very specific advocacy thought. It aligns a lot with the kind of work that we do in social mission and mission-based work. Our clients really understand what's going on. My favorite one is the back-end is the advocate of the reality. Because a lot of the time, the rest of us are dreamers. We like to come up with things. But our back-end developer will come in and say, "Let's just talk about what's really possible and executable in these next three weeks. Because we don't have all of the time in the world and we are very much limited by the constraints of time and dollars." Going through this process and defining what everyone advocates for was probably the best thing we've done in the last year. We've rebuilt our roles. Now we also approach the business of the business with these roles, not just whatever project we're working on.

The other thing that happened as we were doing Agile is anybody who wasn't totally in the game or didn't drink our Kool-Aid had to go. I lost a few employees and I fired a few. Being efficient and working lockstep as a team had such a big dependency on who was actually on board. I also had to let some clients go because they were not on board. The goal, ultimately, to get any kind of development work to move quickly and efficiently is trust. Trust between our team, trust between our clients, trust that I can actually do my job and I can lead the team. As we've been setting these conditions in these roles and running Agile—I mean, running scrum based on the Agile Method. I'm doing that just to make all of the developers happy.

The pros have been that we've had our entire team together. Which, conversely, means, we have a lot more meetings and we have a lot of time. We have these really expensive seven or eight person meetings or two or so hours. We're voting, doing acceptance criteria, running through all of the stories and running them up into all of the epics. It's a lot of time. We're definitely communicating a lot better. But it takes a lot of time to be fast and timely and things need to be more efficient and immediate. It is kind of a time suck and people seem to bounce back and forth a lot more than they used to. Because they're not sitting in a dark room designing a whole website. You have to work as a team and test and look at things and go through an iteration. We've had no surprises on budget and timing, which probably was my most driving factor for moving to this method. Because we are talking about timing and budget all the time. Annie, who is the advocate of the project and budget, that is really her perspective for everything she does. So that is infused into everything she talks about with our clients and staff. We're extremely well-versed on where we are, what we have left, what we're going to have to sacrifice, or if we're going to have to ask for more money. But there is the converse that is the increased project management time and documentation. It does add to that. Running this isn't always the most efficient but the product has been a lot better so it's definitely worth it.

We have increased margins on our products. Before when we were running waterfall, or a shaky version of scrum, if I over committed some kind of feature, I would hire a developer to do it and just get it done to make my client happy and take the load off my team. I would absorb that cost a lot of time. Which isn't the best business decision. But as the advocate of the relationship, I wanted to preserve that. I didn't want to have to charge someone for something that was maybe our fault for not scoping correctly or over committing. This way, we don't have any of that anymore. I've also restructured how I do my freelance costs and billing, so yay for me.

We do see a decrease in the overall productivity because people are running these lockstep, three week processes and there is downtime based on your role. We're trying to find ways to fill in that time. One of the ways that we've been able to do that has been to stagger the times that the scrum starts. They don't all start on Monday, or else we'd have a 12 hour meeting day, which is not humanly possible. So we stagger them. We do Monday and Wednesday and stagger them week to week. That has been helping a little bit. But we didn't know that when we started and then decided to run this in a different process.

The big bonus to doing this is the quality of the work went way up. It's more efficient and we can measure everything. A lot of the work we do is not e-commerce. It's a lot of service-based stuff. It's a lot of nonprofit and social impact. If we're going to try to measure that, this is a huge gateway. It gets our clients really versed in how we do that, and how to do that when we turn the keys over and it's more in their hands.

We're currently developing an MVP for a startup. We have six or seven sprints. The 7th sprint was just for technical debt. We were thinking everything we can't execute we're going to roll into sprint seven and make a backlog just for that one, and roll everything out. But since we've been operating this way, we don't have any technical debt. Which is crazy. I don't think we've ever had a project were we didn't have any technical debt. We still have a little bit of budget left, which is amazing. We're either going to turn that back to our client and say, "We totally came in under budget," or what is probably more likely, we'll spend it on more brand enhancement, interaction enhancement, and a little bit more marketing, instead of just building out the features that we need to hit MVP. Which is really, really exciting and different.

I've talked a lot about how great scrum is. Let me talk a little bit about how we switched to waterfall. It was scary. We felt like we were going back in time. it was also great because we hit our deadline and we made everybody happy.

I'll tell you the story about this project we were running. The goals of this project where we switched back to waterfall was to keep the process iterative and streamlined. We were doing a website for a nonprofit. We weren't building software. We wanted to prioritize the components and features that hit the bottom line first, which is almost always how we run this. We wanted to keep the team really, really small. And we wanted to train the client as part of every sprint so we could offload a ton of work to them, because we didn't have a ton of time. We wanted to make sure we were focused on the things we were building and not doing content entry or something they could end up taking over.

These are the conditions that had to exist in order for this thing to be successful. It was a web build so it wasn't software, it wasn't an app, it wasn't an MVP. We did discovery, a concept, four dev sprints, and we had a launch. This is our plan. We didn't have any extra budget. We couldn't ask for more money. Anything we went over I was going to eat, probably. We didn't want to do that. The conditions in this job that made waterfall possible is that we had a long history with this client. We were in love with each other. We started the build with scrum. Our client knew how hard these decisions we were making were and how complicated they are. They also were hands-on the process the whole time. There was no dog and pony show. We were definitely doing this collaborative decision-making process. In the upfront, with a small team, it did add to project time because we had to talk through everything with them. We had to make sure they understood everything. We had done enough discovery, but just enough discovery. We didn't spend a ton of time doing a ton of research. We did enough to get us started and to understand the landscape and give us some good fuel for prioritizing features that would help them raise more money, get more donations, get more eyeballs on their newsletter. The things they wanted to do. We also had a very, very small team internally at my office. We only had three people on this project. Again, I was trying to keep this thing really lean and small. And we were at the end of the project. If we had started out doing waterfall, which would collect requirements, design the whole website, and then build it, and try to get approvals and content, it wouldn't have worked. They wouldn't have trusted that we were able to makes these technical decisions. They wouldn't have felt they were being listened to. They wouldn't have felt like they had business input on what was priority. In order for this disaster to not happen, we had to have these conditions possible.

We had run through two or three sprints. We realized that we were running out of time. We knew if we kept doing the spring structure, with 2-3 weeklong sprints, we would have gone way over time. We said, "Listen, client. We love you, you love us, everything is wonderful. We want to execute everything you have left on your wishlist. Here's how we're going to do that. We're going to design everything and put it up on your site and we're not going to have a bunch of meetings. We're not going to ask for all of your input. We're going to streamline all of our processes and we're going to come to you in three weeks and we're going to show you the rest of your site. How does that sound?" And they said, "OK." Because they knew we had proven ourselves over and over in the beginning. They knew how hard the decisions were. They knew how to manage the site because we were training as we were building. They knew that our team was capable of making really good decisions in their interest because we had redefined our roles to advocate for them. That was really the only way that waterfall made any sense. We ended up delivering the product under time and exactly how they wanted. They're still one of our most favorite people in the whole world.

I said in the very beginning that we used this Agile framework to run our own business. It's not just about running our projects. It's about being iterative and measurable and testing and everyone owning the problem in our actual company. We've taken that model because it makes so much sense and it really does eliminate uncertainty. In my life, I think that's the only thing I'm ever after. Eliminating uncertainty.

When we looked at the original six Agile principles, we've redefined them. These orange words are the words that we added based on what we've done over time. I know I'm redefining Agile Method, holy shit. But it's not just important to define a measurable goal, as the advocate of reality, my back-end developer would say, we want to define an attainable goal. Something we can actually execute in two weeks. Within our budget, within our timeline, and something that, if we're training our clients, they have the capacity to actually do. Which, to me, is a really big, important thing. Everyone does own the problem, but they own the problem based on what they advocate for. If we're all trying to solve the same problems, all the time, over and over, we're not scalable. We step on each other's toes. This way, we all know that we're all equal. There's no hierarchy. We advocate for different parts of the project and business. Making small steps with visible impact is probably my favorite thing. The thing that's the most important there is everyone needs to understand, number one, the motivations of those small steps, and everyone needs to understand the technical implications of those small steps. For example, the reason we train our clients, I have an open books policy here, is that everyone understands the functioning of the business. Why I would make a decision for the relationship of a client or why someone would make a feature pull or would make or would not make a feature for an MVP. It's the same theory. Validating with our target audience, we're big fans of that. But we're also big fans of not going over budget. What we like to do is, in the way that makes the most sense, based on capacity, timeline, and budget. That means, if I have a question, I might not a huge quantitative study every sprint. Because that would be crazy town. But I might pick up the phone and call somebody who is in our target market and run through something with me. Or I might do a quick key map. Or something that costs almost no money that gets me the results that I want. Again, we're being very flexible and responsive based on what we're trying to find out. Point five is maybe the most important part of all of this, besides number two. Which is, we have to define what success looks like in order to measure it. Which, to me, is obvious. I wrote a blog post last January about a blog post that I wrote about last year, which is hilarious. I had set all of these goals for my business and I had failed to meet them miserably. I really, really ,hilariously went not even anywhere near it. Because I hadn't defined it and I hadn't set expectations correctly and they definitely weren't attainable. They were measurable but they definitely weren't attainable. In all things in terms of business or anything in terms or relationship or anything in terms of building a product, defining that success is incredibly important. Also, when we reflect and adjust and iterate in our scrum, in our three week sprints, is one thing. But we're not just doing that for the product. We're looking at the health of our relationship. Which is directly resulting in the health of our business. The health of the project and the health of the user. It's a very holistic look at, "How do we iterate to make ourselves a better team? To make the relationships with our client better? How do we iterate to make the relationship with their users better? And to make the community better as a whole?" I think if you take this methodology and apply it to a business or a sustainable system or a nonprofit or something like that, really, the way that you execute that could be some kind of scrum, or it could be some kind of waterfall. As long as you have these principles down, it can work really well. That's my whole presentation.