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.
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.
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.”
Over 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.
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