![Illustration of scientific flasks and beakers.](https://mostlyserious.imgix.net/Our-Agile-Experiment.png?auto=compress,format&width=954&)
Our Agile Experiment
We started 2024 with an experiment. After niching down our industry focus to on manufacturing, healthcare, and nonprofits with a tightly defining our set of services, we decided to intentionally open ourselves up to new types of work to see how we may be able to support more industries, solve different client challenges, and continually consider how our existing processes could be modified to better accomplish the goals of our clients.
We called this effort “YFL” or “yess-er, faster, lighter,” which meant saying yes to more project opportunities, expanding outside of our core industries, and right-sizing our process and level of effort to align with the project requirements.
We saw early signs of success in the first quarter and, accordingly, we pushed this concept further to start the second quarter. We introduced a new framework that gave our team permission to rethink how we deliver value to our clients starting as early as the project kickoff. We dubbed it MS Doubtfire—a reference to trying on a new personality or way or working—and Spencer defined guardrails and rules to ensure we maintained quality while encouraging experimentation.
We agreed to run the YFL experiment for 6-months, at which point we would pause to reflect and review what has worked, what hasn’t worked, and what we intend to keep as we move forward. Time-boxing the experiment was important, as it ensures we don’t endlessly try new things without capturing the good, bad, and the ugly of our new approach. It also gives our team assurances that if the experiment fails, we have a rip cord and can revert back to our tried and true processes.
What we’ve learned is that this experiment was needed. While we were and are very good at solving common problems our clients faced, we had lost some of our agility to address novel problems or significantly adjust our ways or working to tackle work outside of our bread and butter.
There are two things that worked, in my view, surprisingly well in our experiment: the creation of a Critical Problem Meeting, and closer alignment to our Core Value of Collaboration with our clients.
![Illustration of a detective board. Orange thread connects multiple items to a central idea.](https://mostlyserious.imgix.net/Our-Agile-Critical-Problem.png?auto=compress,format&width=954&)
Critical Problem Meeting
When we introduced the MS Doubtfire framework, which encouraged exploring new ways of working to accomplish our client’s objectives faster and better—we knew we needed a method to create alignment among our teams at the outset of a project. Changing the way work happens without clarity across our team was a stumbling point in the first quarter with the YFL approach, and some of our projects incurred more internal friction as team members had unclear expectations about how we were working.
Enter the Critical Problem Meeting. This session occurs at the outset of new projects, between the point of receiving a verbal agreement with clients and our client onboarding process. The meeting aims to bring our strategy, consulting, design, development, and content teams together to align on the critical problem(s) we are setting out to solve for our clients. This sounds simple but it can be, in fact, terribly difficult. Some clients come to us and ask for a website redesign, but “bad website” isn’t necessarily the problem they’re trying to solve. Rather, they’re trying to solve a sales problem, or perhaps an awareness issue, and a website seems like the best solution for those issues. Our job during this phase is to create radical clarity around the specific problem(s) our clients need to resolve, and then dream up all the ways we could bring our expertise to bear. Then, after we achieve internal alignment, we determine the level of effort each service requires to best address the critical problem(s).
Varying Critical Problems
Some clients come to us with a need to deliver information as quickly as possible to their audience. This could be a government entity tasked with public awareness, or a business building an online resource center to deliver value to prospective customers. These websites and applications often require more in-depth content strategy, information architecture, and user experience design.
Other clients might have website content and structure in a good place, but a new brand overhaul has spurred a website redesign to level up the visual and interactive elements and push the brand into the same territory as national or global leaders. In this instance, we may spend less time on organization of information and more time on visual concepts, user interface design, and front-end development, to enhance things like interactive elements and engaging animation.
The list of critical problems our clients face is nearly limitless, with each client addressing at least one critical problem that can best be solved by a process tailored to reach the defined goal. We use these meetings to understand the problem and right-size each service to best align with the need. That doesn’t mean we’re throwing our process out of the window, rather, we’re scaling the most important parts up and the least meaningful parts down.
![Illustration of two speech bubbles representing communication and collaboration with our clients.](https://mostlyserious.imgix.net/Our-Agile-Client-Collaboration.png?auto=compress,format&width=954&)
Improved Collaboration with Our Clients
After defining the critical problem, we take a detailed project brief back to our client and begin moving forward. This is the second area in which we’ve made quick gains in our ability to deliver better results to our clients.
As part of our MS Doubtfire framework, we aim to put work in front of our clients earlier in the process. Often as early as possible. This means that clients are interacting with less polished work, but they’re seeing it at a point where they can better shape later outcomes. The result is that we learn if we’re on track or off track earlier. If we’re off track, we gain information and correct misalignment before we get too far along. If we’re on track, we still gain information that will help us improve our work as we continue. A true win-win.
Our past process attempted to have us arrive at the ideal final product too quickly. Ironically, this slowed us down, because the ideal final product needs to go through all the hard phases before it’s ready to go out into the world. It needs to live as an inconsolable infant, experience the terrible twos, deal with acne and teenage awkwardness; only then can it graduate and go out into the world (or graduate and live at home while it “figures itself out”)..
Some years ago, I received some great business advice. An entrepreneur opened a brewery and, using the lessons he learned buying and building several businesses before it, he tried to skip several steps ahead. The result was that each mistake still had to be made, it was just more expensive to make them. Such is the nature of our projects as well.
Our experiment has uncovered a better way to collaborate with our clients, given our team better tools to achieve success, and added new methods for learning how to best reach our clients’ goals.
The Next Iteration of Our Experiment
This isn’t the end of YFL or MS Doubtfire. We’ll pause to reflect, but then we’ll continue to iterate. The best way we know to improve is to always be curious, try new things, and remain open to occasional failure.