the life and work of tim krajcar:
technologist, husband, father, and musician in portland, oregon

Agile Processes As A Responsive Design Prerequisite

02 November 2012 - by Tim Krajcar

I’ve been drawn to the simple principles of agile software development ever since I first discovered them about ten years ago. In any one day, I’ll move between at least 5-10 different projects or sub-projects - a mix of directing developers, writing some code myself, handling support tickets on existing projects, architecting new builds, and so on. It’s become incredibly apparent to me that the agency world, as much as some forward-thinking colleagues and I have endeavored to bring agile into our processes, is deeply locked into waterfall processes.

Sure, we may be emailing PDFs and projecting PSDs instead of gluing mockups to black poster-board and putting it on an easel, 1960-style, but the overall process hasn’t changed:

  • receive project, ask lots of questions, get definition
  • information architecture/wireframes, get client approval
  • present 2-3 designs, client picks one, refine
  • build a site, striving to be pixel-perfect to the designs that were presented and approved
  • argue with the client about all the features they thought they were getting but never wrote down
  • launch, usually with a subset of what was originally planned by the client, either because they never told the agency or because a few things turned out to be time pits and couldn’t get done on time

Some projects are better or worse than others, but this process, with variations, is extraordinarily prevalent.

I firmly believe that moving to an agile model is not only a solution to these problems, but will become a required way of doing business, because web development is no longer about creating pixel-perfect HTML renditions of design comps. We live in a responsive design, multi-form-factor world, and our processes need to reflect that.

Working with agile when you have external customers is a lot harder than when you’re an internal IT or dev group serving internal users. I have no doubts about that - I see it every day as we move towards a more fully-agile model. Involving customers directly in the ‘sausage-making’ is scary stuff and requires a decent amount of careful planning as well as some truly careful management - agile is not the same as collective democracy, and when you allow it to be, it can quickly become even more process-driven and stagnant than a waterfall project. It’s going to take a sea change of how we work, from business operations and project management to design and development. We’re going to have to completely re-think how we handle client relationships, presentations, approval cycles, and customer involvement in milestone planning.

But along the way, we’ll not only be able to properly deliver modern, responsive web solutions, we’ll also deliver highly functional solutions that make our clients happier, for less money - and we might even launch on time.