Making agile development and design work

The agile dream: better everything

In Agile methodologies, design and development — working closely in tandem — save time and produce better products because the time between iterations can be radically reduced. In other words, the time between when a mistake is made, it’s tested, and corrected can be almost instantaneous because all of the team’s members and stakeholders maintain close communication with one another.

If the developer shows you a show/hide widget as soon as he finishes it, you can immediately give him feedback: it’s too fast; the target area is too small; whatever.

Agile only works for small, independent teams

Agile design and development works in small teams of experts with almost total control over the product. Once the team grows beyond 4-5 members, or control over product development shifts outside of the team, then the rapid communication and iteration at the heart of Agile begins to fail.

Your average business meeting offers a good example. In meetings with four or five people, you get more accomplished than meetings with nine or ten people. Similarly, if you spend an hour in a meeting coming to a decision, you’ve wasted your time if someone higher up the ladder mandates something different.

In larger product teams where people outside the development team control product specifications, agile design and development are still possible, but it’s less likely they work in tandem. And the time between your iterations starts to get longer and longer, less and less agile.

In lots of companies, business gives deadlines to Development and changes to the Design team. All of a sudden, your agile design and development team goes from having a common goal to two separate goals: development’s worried about time, and design’s worried about changes.

Agile development helps manage requirement changes

In places where design and development start working toward different goals, agile development can help development teams manage requirements (prevent scope creep), timelines, and quality.

In fact, in my experience, these issues are often the impetus behind a development team adopting agile methods like scrums and sprints.

However, in more distributed teams with complex requirements environments and inputs, you can’t design a product in 30 day development sprints.

Agile design in large organizations: agile waterfalls

You might be able to design products in 30 day sprints, and in these cases, you achieve many of the same advantages of development sprints: focused objectives, rapid iteration, and change management. And after the design sprint, you can hand your models off to a development team that uses whatever development methodology they like, agile or otherwise.

There’s an obvious complaint here: this is a waterfall approach. However, Waterfall approaches are not necessarily bad. Managed well, waterfall processes can — and do — create good products. Secondly, large teams and complex requirements processes make close, full-team collaboration impossible. In these organizations, waterfall processes evolve, almost as a matter of course.

The chief evil perpetrated by the waterfall process is that people down river never talk to people up river. The silent treatment isn’t inherently a bad thing. It becomes a problem when down river doesn’t understand what up river said, and then they have no way to discover the misunderstanding.

Communication short-circuits the waterfall process

You can short circuit the waterfall process by insisting on close collaboration with both development, business, and representatives from other teams. It’s the lack of communication that makes waterfall processes bad. Any way you overcome these communication gaps makes the business hurdles and hoops irrelevant.

If you work with development teams adopting agile methods, work closely with them to understand how they prefer you communicate the product design. Do they want wireframes? Flows? Business Requirements Documents?

Similarly, make sure you set aside time to work closely with them during the sprint process, so you can offer quick input on iterations. Waterfall or agile, if you’re not quickly closing the communication loop, you risk introducing unnecessary problems into the product design.

Agile is all about focus, so communicate the focus

At their heart, agile methods are about focusing on the right thing. The better you communicate the focus, the better your products will be, regardless of whether or not your teams adopt specific agile methods.

Combined with clear product requirements, design guides help developers stay focused. When you humanize a product’s users and communicate a product’s context, development teams can answer their own questions.

Personas, by nature, personify one-dimensional users, turning them into real people developers can empathize with. Base the fidelity of your personas on what best communicates the user model. Whether or not the final personas match “real personas” is irrelevant. Your goal is to communicate to the development team. Speak their language.

Similarly, scenarios help communicate how a product will be used: the flow and context of use. Like personas, create scenarios with the development team in mind. Most developers would rather superglue their toes than read design mumbo-jumbo. Keep it brief. Get the idea across in as few interesting words as possible.

They say Hemingway wrote a story in six words: “Baby shoes for sale. Never used.” If you can write like Hemingway, quit your day job. If you can write six word stories for your development team, they’ll love you and your products will be better.

Personas and scenarios are just two ways you can communicate with developers on paper. Any way you can communicate design goals and context, the better and more agile your process, and the better your products.