Lincoln Anderson / Culture Digital Strategy / November 20th, 2014

Applying Agile Values in a Digital Agency

Agile methodologies have come to define almost everything we do at 352. Working as an agile digital agency, we’ve streamlined our processes, created happier, more efficient teams and have seriously ramped up the quality of work we are able to produce.

The agile manifesto guides us to value these things on the left, more than the things on the right:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

There is a lot of wisdom in these simple values. But can these values work in an agency-client relationship, or are they only applicable “in house”? I believe they apply to any arrangement, but there are extra challenges that we have to overcome with our clients to ensure that agile values are strengthening the client relationship rather than impeding it.

client-meeting

Enter the Client

Working in an agency, you have an extra layer of complexity in the mix: the client relationship. There is a stigma attached to that relationship. We want to make our clients happy. We want them to be treated fairly, and happy to pay their bills because of the great value we’re producing.

At the same time, our client is always a little nervous. And rightfully so. They are taking on a huge, complex project, and working with a sizable group of people they’ve only just met. Plus, we’ve shortened the development cycle to weeks instead of months. We work fast, and when every conversation is critical, you don’t want to miss a beat.

These fears and desires are natural. How we respond to them has a much bigger impact.

Derailment #1: “The client is always right.”

This comes in a few flavors, like “they’re the ones paying the bills” or “it’s their project, not ours.” While it can certainly be true, this mindset creates a divide between the product owner and development team.

mind-the-gap

The client’s voice is always important, and their problem is always the right problem to solve. But they aren’t always right. In fact, clients are usually looking for experts to tell them where they are wrong and how to course-correct. Debating differing points of view is uncomfortable for some people, but it’s part of being a consultant and a partner. And, it’s a huge part of educating, growing a relationship and finding success together.

Remind yourself and your team: We aren’t building a project for the client; we’re building it with the client. Being agile means collaborating whenever possible, rather than negotiating.

Derailment #2: “We’re an Agile shop. We use Jira.”

tracksOver the years, I’ve worked alongside many folks who have found it easier to hide behind processes, rather than engaging clients with open dialogue. Many people lack the confidence and experience to speak from the heart; they haven’t learned how to talk about the importance of trust, creativity and optimism inside the drab walls of a typical office. So, they fall back on “real,” hard-sounding things, like names of enterprise software applications, years of experience, 2-week sprint schedules and other trivial facts and figures.

The problem is that every time we do that, we train our clients to value those things as well. Soon, the client will be evaluating our agency on things like story points, hours tracked, and other “performance indicators” that mean nothing.

When we communicate our core values and illustrate how we support them, we tell a story our clients can get behind. We give them a chance to understand us on a deeper level. When we celebrate our successes and take ownership of our failures, our clients can begin to trust us and don’t need to seek proof of our value inside of spreadsheets and checkboxes. Being agile means interacting as individuals, rather than using processes and tools as a crutch.

Derailment #3: “The client already paid for it to be built that way.”

People don’t like surprises, especially when their job or their dream is on the line. Contracts are scary things written in bold, black ink. And sometimes, what’s written in an agreement turns out not to be the best course of action. Everyone who has their name attached to that agreement knows the cold truth: we need to change our direction, and that means changing our minds first.

Go ahead and take a risk. Image credit: The Fayj
Go ahead and take a risk. Image credit: The Fayj

But too often, it doesn’t happen. People build out the poorer solution according to the contract. Concerns and questions are silenced, and – inevitably – the surprises come later, and they are much more painful. They come in the form of dissatisfied users, abysmal web traffic or software bugs. By that time, it’s too late.

Why does this happen? No one wants to appear “weak” by admitting they were wrong. No one wants to be the guy rocking the boat. And so they follow the plan, even with all of its flaws. This isn’t a mistake only junior developers make -– even seasoned executives are not immune to “staying-the-course” at all costs.

But agile web development is all about change. It’s about being smarter today than we were yesterday. It’s about admitting to ourselves that we don’t have all the answers, and that’s ok – as long as we use our heads and commit to getting the right answers quickly. It’s about responding to change, even when a plan is already in place.

Getting Back to Our Roots

The term “agile” has been hyped up, twisted around, used and abused for years. But the fundamental meaning of the word rings true with anyone who has experience building software or building businesses: communicate, be flexible and do good work. At 352, we continually try to pass on that wisdom to our clients. We believe that our role is not just to design great software, but also to help our clients build stronger organizations and more meaningful customer relationships.

Image credit: Jeff Sheldon

  • Christopher Burns

    You’re right that it’s really easy to get caught in the trap of trying to keep the client happy because they pay the bills. But it’s a great point to remember that it’s a collaborative effort. They bring the money, we bring the skills and together we make something great.

    • http://352inc.com Lincoln Anderson

      There’s a similar situation graphic designers find themselves in. They have to communicate with clients in a tactful way: My job is not to make something *you* like, but to use my skills to help you achieve success. ie, Craft a design that works for the end consumer. (If the client also likes it himself, that’s just a nice bonus.) Thanks for the feedback Chris.

  • http://www.slinky.info/ Digital Agency

    This sounds so great and interesting.

    • mikecush

      Can easily say that it’s transformed our agency and the relationships we’re able to build. Happy to chat more about it if you want to drop us a line.

  • bart vermijlen

    Hi Lincoln. Interesting blog post. I’ve touched on this topic in my book The Agile Agency – http://www.leanpub.com/theagileagency. I’d love to hear your feedback. Cheers. Bart

    • http://352inc.com Lincoln Anderson

      Excellent, my team will love that Bart, I’ll check it out!

  • Diogo Freire

    Dude. How can I contact you if I have more questions? I reckon whatever you’re doing it’s working, and I’m keen to hear you talk about more about it. 🙂

    • http://352inc.com Lincoln Anderson

      Sure! Let’s connect on Twitter @BrokenLinc

  • Jesse Romeijn

    Hate hearing about how people think that they’re doing agile just because they have this or other software and are ‘following a process’. Agile is not about getting stuck to a process tool, it’s a set of principles and rules that can be applied and flexed in order to suit a specific business need.
    I’m doing kanban with my design team, and how we started was with getting to know the kanban values (started
    of with this article here: http://kanbantool.com/kanban-library/getting-started/introducing-kanban-through-its-values),
    not by setting a process in a tool (although this we have done later on, when we’ve outgrown the analogue
    board’s capabilities 😉
    But man, an approach and a value is always above an even most technical process.

    • http://352inc.com Lincoln Anderson

      Thanks Jesse, it sounds like you’ve observed some of the same pitfalls we have. Sharing values and principles helps elevate the conversation! BTW if anyone has trouble with Jesse’s link above, try removing the end parenthesis “)” from the URL.

      • Jesse Romeijn

        Thx for this. Yeah, we had the same issue a while back, so I get what you meant.