1. From Waterfall to “Agile-ish”

The original best practice for web design was the Waterfall process, adapted from the manufacturing and construction industries and first implemented in 1956. Many shops still use it. In 2001, The Agile Manifesto was released in direct reaction to the weaknesses of Waterfall and BDUF (Big Design Up Front). The manifesto defines Agile in terms of what it is not: process and tools, comprehensive documentation, contract negotiation, and following a plan.

At the end of the day, all of these techniques are aiming to solve the same problem: Communication.  Waterfall gives us communication in the form of “deliverables” that can then feed the next phase of the project. Agile contends that communication should happen throughout the project. Here at Tank, we use more of an “Agile-ish” approach (if I may borrow a coined word from Kristin Ellington) that focuses on supporting good communication throughout any project.

2. Every project is a conversation

Our work inherently requires communication (and lots of it!) because things inevitably change throughout the project. Things change because we’re all human with very different understandings of written documentation.

“At best, users will get exactly what was written down, which may or may not be anything like what you really want.”

– Mike Cohn, Succeeding with Agile, 236

It is for this reason that Waterfall doesn’t really work for the software world — and why Agile came about. Every point in the Agile Manifesto is about HOW we should communicate. We interact and collaborate, so that we can build together. Agile was a reaction to Waterfall and “Big Design Up Front” that tried to define everything in copious amounts of documentation before design or development began. The problem is that Waterfall and BDUF rely on the false assumption that everyone has the exact same interpretation of that documentation.

We’ve heard it said that “every project is Agile in the end.” If no one has been talking until it gets to the development team, suddenly there needs to be communication between UX, design, copy, the client, and development to get the site built.  Now, in Waterfall, there HAS been communication. There have been all kinds of “deliverables” like functional specifications, requirements, wireframes, personas, PSD’s, etc. The problem is, as Mike Cohn points out in “Succeeding with Agile,” those written communications are less precise than they appear and do not provide a way to iterate over meaning.

“[I]terating over meaning is missing in documents.” – Cohn, 237

Documentation is fine, but it should be the start of the conversation, not the end of it. What happens when teams don’t communicate? All of those conversations just get pushed to the end as the deadline looms. Kristin Ellington describes this well:

“It is about communication and it is about human messiness because human messiness is the reality. As much as waterfall tried to pretend that everything was buttoned down, and that was really going to work out just fine for everybody, and it was lower risk, at the end of the day it was just as messy as anything else. It was just about delaying the messiness to the end of the project where everyone was really upset.”- Kristin Ellington, The Web Ahead, Episode 62

3. Agile + agency = “Agile-ish”

There can be some issues with all of Agile tools and processes in an agency setting. First off, web people often don’t have the luxury of working on just one project at a time. So, a stand-up meeting of 20 people, each giving an update while the other 19 have no idea what they’re talking about, is not effective (to say the least). We don’t have to follow every tenet of Agile software process in order to make it work. We can use what makes sense for us and share our experiences with like-minded experimenters. Kristin Ellington talks about how everyone thinks that everyone else has responsive website workflow figured out, but that we’re all working to incorporate responsive workflow into our organizations. Everyone can incorporate Agile techniques and ideas into their process in ways that work for them. Every organization is different, but here’s what we’ve found to work for us.

Prototype early and often

The prototype in web development is a form of Agile’s “working software over comprehensive documentation.” After all, it is software. A prototype, unlike a document, but like software, is inherently interactive. A prototype demands a conversation. As Stephen Hay points out in Responsive Design Workflow: “web design is not only visual. It’s a combination of visual elements, content, and interaction; it’s an experience.” By getting into a prototype as early as possible, we can more easily see and, therefore, respond to interactions. It’s a truer tool for communicating ideas because it puts all the pieces together.

By prototype, we mean something that’s testable to help us make decisions. It can be a rough HTML implementation of a responsive design concept, a Drupal module for tinkering, or a full usability prototype. The prototype aids the UX or design thinking so we all have the best information for our decisions. Here at Tank, we prototype as much as we can, as soon as we can. Typically, this means we’re starting to play with the ideas that our designers are exploring before the client has “signed off” on the design. It encourages conversations around something that’s closer to the final product than a flat image or a written document.

Solve problems together

Every discipline is involved in all phases at Tank. That means developers are involved in discovery and design. UX designers are involved in design and production. Designers and copywriters are involved in discovery and production. This is not a unique idea in our industry. For example, Ikea has been working on it for years:

“Very early on in the design phase, our product developers and designers work with a diverse team of technicians, manufacturers and specialists – often right on the factory floor.” – Ikea, Democratic Design

We solve problems together. What we don’t do is all sit together and noodle everything all day. We also don’t impose endless meetings on everyone to make sure we’re all “up to speed.” True collaboration starts with little things: inviting developers to those early meetings, encouraging designers to ask developers if they’re stuck with a mobile navigation — fostering an environment of communication. It doesn’t happen overnight, but over time, people on the team start to see communication as a boon to their work instead of an obstacle.

When I was in high school, I remember only one motivational speaker. I can’t remember most of what he said, but I remember this one line from his speech: “People tend to support what they create.” It stuck with me because it resonates with my professional experience. If you help build something, you get behind it. Get everyone involved when building websites and then everyone will support it. Instead of UX people only building wireframes and designers only building PSD’s and supporting those “deliverables,” we’re all working together to build a beautiful website.

Get clients involved

Let’s not forget the client when we’re talking about inclusion. One of the goals of stakeholder interviews, for example, is to make them feel part of the process. Here at Tank, we heavily involve our clients in our process. We ask them to help us — to work collaboratively with us, as we build their site and/or brand together. Why? First, because people tend to support what they create. But you know what else? People tend to support each other when they build things together. The process of building something together tends to bond a team if everyone is involved in making decisions.

“It’s really about having one cohesive team as opposed to a client team and a[n]… agency team… If your client walks away and thinks, ‘Wow. I just designed this website and I did the most amazing job ever.’ That’s the best thing in the world. Because of course they’re going to come back and hire you again.” – Kristin Ellington, Web Ahead Episode 62

This is really the difference between “vendors” and “partners” in client-agency relationships. Vendors do something for you. Partners do something with you. The more you involve your client in the process, the more likely you’ll graduate from a vendor to a partner.

Step away from the screen

Responsive web design tools are not part of this article; however, there is one tool that we’ve found to be most effective. It’s not a replacement for Photoshop or Illustrator. It’s not an improvement on Invision or Omnigraffle. It’s a stool on wheels — and it’s the best collaboration tool out there. At Tank, there is one of these in each quad. It’s such a simple idea but, by its very nature, it invites collaboration. This brings me to my last point: the physical environment.

“Who is the most important process person? The one who arranges the furniture.” – Gerald Weinberg, author of The Psychology of Computer Programming in Succeeding with Agile, 413

I can’t say enough good things about open environments. I remember when I moved to Tank from a bigger agency, our awesome HR director asked me if it bothered me that I would be leaving my private office to sit at a desk like everyone else. Having worked in an open environment previously, I knew that set-up would give me what I was missing at the job I was leaving: more communication and better relationships with my team and the rest of the agency. Because I’m not separated from everyone else, I pick up on issues before they become a problem and I’m back to learning with my team. Alistair Cockburn calls this process of taking in information without paying direct attention to it “Osmotic Communication” (Cockburn, 111). I know what’s going on at all times — and that allows me to help. Apparently, I was not the only one who found the benefits of an open office plan.

“Surprisingly, the team liked the open space concept from the beginning…they found that the interaction actually helped them resolve issues faster and allowed them to learn from each other.”  – Syed Rayhan and Nimat Haque – in Succeeding with Agile, 414

Not only does an open environment contribute to better communication, just having people sit together also contributes to better working relationships. Back when I was studying psychology in college, I remember being particularly interested in the social psychology concept known as the “Proximity Principle.” Basically, it’s the theory that people will tend to form personal relationships with other people who are close by.

“First, human beings like things that are familiar to them. Second, the more people come into contact with one another, the more likely the interaction will cultivate a relationship.”

– Wikipedia, “The Proximity Principle”

The Proximity Principle has a real impact on communication because we tend to communicate with people we have relationships with. In my experience, projects have gone more smoothly (and been more rewarding) in companies that seat people together. At another of my previous jobs, I worked in a large agency. At first, all of the “digital people” were seated together downstairs in a mostly open environment. We all got to know each other and our projects went as smoothly as they could. Then the company made a decision to move all of our designers to a different floor. New people came and we never really got to know them and people with whom we had great working relationships left. The communication dropped off considerably and with it went quality, deadlines, and morale. When I think back to all of the places I’ve worked, I’ve been most proud of the work when we were all seated together. Teams that sit together, create together.

Let’s make a new model, together

Process should facilitate communication because communication can and will be misinterpreted. We have seen that our current models don’t really offer us a best practice in the responsive design world. At Tank, we’ve chosen to break the rules of our traditional web design process simply because the old rules from other industries didn’t apply anymore. As we all seek a new process that works, it’s important to recognize and share organizational changes that can help people everywhere work and create better, together.

In short:

• Good communication is the key to the success the project.
• People will support projects if they feel involved.
• People get involved through communication.
• Communication and close proximity foster relationships.
• Relationships build trust and good communication.