As an organization matures, the idea of processes—the “how we do things around here”—inevitably becomes a frequent topic of conversation. This happens for good reason: processes eliminate inefficiencies and make it easier to onboard new team members.
The ideal process is like Shangri-La, El Dorado and the perfect sandwich, all rolled into one. It’s fictional, unattainable; yet organizations across all industries regularly seek it out. idfive is no different—collectively as as an agency, we continue to hunt for ways to do things faster, inexpensively, better.
In informal chats about process, many fivers shared their thoughts and challenges, and a common theme emerged: Few have and most want full end-to-end ownership of a project. In a world where we juggle 20-30 web projects at once, as soon as a resource finishes their part of a project, they’re pulled into something new—and only see their work in passing from then on.
Weighing Waterfall Vs. Agile
Traditionally, websites (and other software) have been created using the waterfall methodology. Waterfall is a linear approach where all phases of a project happen in order—requirements, design, development, testing and deployment. Things flow into one another, much like a waterfall.
At idfive, we’ve traditionally followed a very similar model: discovery, UX and wireframing, design, development, quality control and deployment. This method for developing websites has many benefits—chief among them, formal starts and ends to phases of a project. With this, you control costs by controlling who is actively working on a project at any one time.
From idea to final working product, a Waterfall project can take months, if not years, to finish. Therein lies the risk: what if the problem we’re trying to solve changes while we’re in the middle? If stakeholders only look at the final product, how do we even know we’re getting it right?
In the early 90s, the Agile methodology emerged as an effort to address these failings. While Waterfall teams deliver a working product to stakeholders at the end, those that use Agile deliver working code every two weeks. Agile teams are founded on working collaboratively, soliciting feedback from key project stakeholders, iterating and repeating the process. Despite its rapid deployment approach, Agile isn’t necessarily any faster or more efficient. It still may take a team just as long (or longer) to create a fully functional product using Agile than if they used Waterfall.
Waterfall is steady, measured and regimented. Agile is rapid, collaborative and iterative. But that’s not to say that Waterfall isn’t collaborative or Agile isn’t measured. Contrary to what many Agile evangelists may tell you, there is no “best” method; each has strengths and weaknesses that an organization must weigh against one another.
Waterfall made the most sense for idfive and for our clients for decades. Many of our clients are large universities and organizations that necessitate decisions be agreed upon by many people. Our clients also are busy people with many other responsibilities that prevent them from devoting the on-demand focus needed for an Agile project. Another less exciting (but no less important) point: when it comes down to it, a waterfall project is easier to scope. So then what can idfive do to provide the best service to our clients while meeting deadlines and producing quality work?
Enter: Lean UX
Technically, Lean UX is a flavor of Agile. It has many of the same collaborative philosophies of Agile, but gives organizations the flexibility to adopt the aspects that make the most sense for them. Simply put, Lean UX is whatever we want it to be. While Lean UX has a number of different tenets, here are three that we’re championing.
Any good hiring manager knows that unicorns don’t exist. The same goes for the single-minded, only-good-at-one-thing types. None of us are unicorns, but we’re all multidisciplinary by nature and have experience working outside of our lanes. It makes natural sense to capitalize on that experience and build teams across all disciplines. In Lean at idfive, all project teams have a member from user experience, design and development. We were already doing this in most ways; but now, it’s central to the process—not ad hoc.
When making a wireframe, UX gets buy-in from design and development. When making a pixel-perfect mockup, design gets buy-in from UX and development. When coding the final product, development gets buy-in from UX and design.
With this approach, team members have an ownership in not just their own work, but the entire project. Just because it’s before or after a team member’s “turn,” it doesn’t mean they have any less responsibility in making sure the final product is a success.
All web projects are built on details—from the color of a button to the central goals of the work. Unfortunately, these details, critical to a project’s success, can be lost in between phases of a project because they’re buried in documentation or too much time has passed since the decision was made.
A shared understanding of project details amongst team members is central to Lean UX and is key to our process improvements at idfive. To address this, every project now has a formal “strategy delivery” meeting to discuss recommendations with UX, design and development.
In many ways this step simply formalized what we’ve being doing; however, this in conjunction with informal check-ins throughout the project lifecycle, help to reinforce project details and why we’re doing the work that we are.
No Rock Stars, Gurus, or Ninjas
We know that a UX-er is not the only person with great ideas about UX. The same goes for designers, developers and their work. A Lean Workshop—a brainstorming session—is a mandatory part of every project. Immediately following strategy, UX, design and development all meet to sketch and find ways to execute on the strategic direction.
At the end of the workshop, UX has what is needed to finalize wireframe(s) and design/development know the direction of a project, having participated in creating a solution. With the Lean Workshop, we are embracing collaboration and are owning work as a team rather than individually.
We haven’t changed simply for the sake of change. Like everything we do at idfive, we’ve been measured and thoughtful about these adjustments. Some aspects of Lean fit naturally into our web process, while others don’t. We’ve taken small steps to find the perfect balance between Waterfall and Agile.
In the end, it’s all about improving the final product for our clients. The passion fivers bring to the work we do is evident in our desire to find new, more efficient ways to collaborate and deliver kick-ass projects for our clients.
Now if only we could find that perfect sandwich.