Cognition

• August 23, 2012
• Permalink
• Short URL

Related topics:

Process

Agile

Waterfall

• Brett Harned
• @brettharned
• Project Management Director
• Brett’s articles Feed
• Bio on Happycog.com

“Agile” is one of our industry’s favorite buzzwords. Everyone’s doing it! If you’re working Waterfall, you are so 2009. I understand why people love this buzzword— the name alone sounds like something we should be using in the web industry, because it seems to mean we’re working faster. You may be working faster with an altered Waterfall process, but if you’re a web development agency working with clients, chances are you’ve altered Agile to work for you. I am no Agilista, but if you’re not using true Agile, please stop calling it that.

Let me take a step back. I love the idea of modifying a stagnant Waterfall process by doing things more quickly and efficiently. But those minor modifications don’t make your process “Agile.” At an extremely high level, Agile is an approach, typically used in software development, that helps teams respond to the unpredictability of building software through incremental, iterative sprints. It empowers the team building the product to make decisions based on a set of requirements and deliver on them. When you’re working with clients, that is often impossible for a number of reasons, like the subjectivity of design or a client’s ability to stick to a timeline.

There are also Agile standards for collaboration and documentation, which are defined in the Agile Manifesto. If you’re working true Agile, this is your process bible. We worship at the altar of the client, so our principles are based on the following:

1. Adapt process to support the client’s capabilities.
2. Some conversations have to occur in person. Accept no substitutions.
3. Transparent communication is the best kind of communication.
4. Great ideas come from everywhere.
5. Be accommodating, but assert expertise where needed.

Some of these principles might cross over with Agile principles, but Agile spinoffs like Lean, Wet Agile, Scrum, and Extreme Programming (extreme!), etc. tell us all we need to know. Variations of Agile were born out of a need to do things differently. The difference for us is how we approach each project: they’re all unique, with unique clients and users. So, we use various methods to construct a project process that works for us and our clients on each project.

Wanting to be Agile

At Happy Cog, we are constantly trying to improve our process. Recently, we’ve run tasks like UX and graphic design concurrently to save time and increase collaboration. It’s been an interesting learning curve, but we’re starting to reap the benefits. At our core, we want to be more agile; we’re embracing change, continuing improvement, being as flexible as possible, and adapting as we see fit. The thing is, we won’t ever truly be Agile, as the Manifesto states. That’s okay, as long as we say what we will be.

Blame it on the clients

Sorry clients, but you’re the reason we can’t fully work Agile. At the heart of it, we’re in the client services business, and we want our clients’ input to make our projects successful. Each site that Happy Cog has launched has benefited from good client collaboration and interaction. It starts with our Project Definition phase, where we gather as much institutional knowledge as possible from our clients through research, analytics reviews, and stakeholder and user research. From there, we deliver a brief that outlines our understanding of the clients, the design problem to be solved, and the project at hand. We deliver that to our clients to make sure we’re in agreement on what we’re about to build together.

When we do start working through tough UX and design decisions, we seek client input. We propose ideas and have conversations with our clients about what will work best for their users. Could we do that in sprints? Perhaps, but we won’t, because it doesn’t help facilitate the conversation or advance the experience. In fact, it seems to turn the user experience into a reactive exercise devoid of broader possible executions.

When we get into an engagement, we assess our clients’ team and its methodologies. We’ll make recommendations on what we think will work in terms of process and stakeholder reviews, but at the end of the day, we’ll adapt to what our clients think will work for them. Within that expectation, we’ll apply the process that typically works for us. After all, we know what will make our work better. Sometimes it’s waterfall, sometimes it’s Agilish. Whatever it is, it will have to work for us and our clients.

Where does it work?

I see potential for us be more more agile in development. We essentially deliver front-end code in sprints now, and we often will set up a CMS development schedule that is based on sprints or check-ins to show progress. Once all of the “look and feel” decisions are out of the way, our developers should be able to roll through and just build everything. Lately, that hasn’t been the case. We’ve had a few late-in-the-game changes that require late design or UI decisions to be made. So, even then, we’re breaking true Agile methodologies.

We’ve also done some experimentation with working in sprints through the design process on a few recent projects. Essentially, after a client has signed off on a concept, we go in to three-week sprints where an internal design deliverable is created in the form of a PSD. That’s delivered to a front-end developer, who then delivers coded page designs to the client. From there, we’ll get feedback that can not only affect the design system that we are building, but can also affect front-end code. Sure, in most cases, the design will be edited in code, but putting that much work in front of a client without prior sign-off of a wireframe feels pretty risky. That’s the thing: you have to be okay with some risk when you’re Agile. But still, the fact that we need a concept approved by the client means that we’re just not Agile.

I think that if Happy Cog wants to truly embrace Agile, it will have to be on an internal project. Removing the client side role (figuratively), we could assemble a team, build requirements, and then work off of them to create a solution through iterative sprints. Maybe we’ll try it someday, but when it comes down to working with clients, I don’t think we’ll ever truly make Agile work.

What’s in a name?

Our process is just that: our process. It isn’t all Waterfall or strict Agile; it will change based on the project and client needs. As soon as we get comfortable with a defined tool, technique, or process, the time will come to adapt to a new set of standards. Until then, we just have to figure out what we should call our process (hint: it’s NOT Agile).

What process do you use? Are you guilty of using the buzzword? Or have you made true Agile work in web development?

Back to Top

Want to hire us?

Get in touch. We’d love to chat.