Over the summer, a small team of Engauge employees pulled off an extraordinary feat: in 6 weeks we produced a site for a major client, from scratch, that receives approximately 2.5 million page views per month.  At the outset, we were in an uncomfortable position for any project team: we had a tight deadline, no functional requirements, no visual/creative program established, and not much of an idea how the new site should behave.  There was only one way we could possibly produce a quality product in such a short amount of time: we would all start from zero and work in parallel, we would produce flexible assets and we would react to each other’s work as we progressed.

As Team Lead for the production effort, I felt obligated to identify a process that would allow team members from far-flung disciplines like graphic design, behavioral research, and programming to work in parallel without leading to chaos and disruption.  We borrowed heavily from the Agile software development process and came up with a strategy that we’ve coined “Interdisciplinary Agile.”

The tenants of the Agile philosophy are succinctly described (in under 70 words) in the Agile Manifesto. The success of an Agile project hinges on the quality of communication between internal production team members and between the production team and the client.

The most fundamental piece of our strategy was the 15-minute daily “standup” meeting. Every day the client services team would get together with anyone who was currently producing assets for the website (i.e. wireframes, user survey results, creative comps, or code) and each person answered three questions:

1. What did you do yesterday?
2. What are you doing today?
3. What roadblocks are preventing you from accomplishing your task?

Often, standups would precipitate small, quick break-out meetings between team members to address more complex issues.

Another important focus of our strategy involved building our deliverables within two-week “sprints.”  The idea is to define tasks in such a way that after two or three weeks, you’ve produced something you can demonstrate (and it doesn’t always have to be pretty).  We produced functioning database access code (demonstrated via an incomplete first-draft user interface) in the first two-week sprint and finalized the user interface in the following two-week sprint.  After the first four weeks, we had essentially completed the site; however, we provided another two week “client acceptance” period where we accommodated client requests for changes.

As a team, we benefited greatly from working concurrently; we managed ourselves effectively and took ownership of the work we had to do.  Great ideas that came out of the flow of the project could be incorporated into the site in short-order and everyone had an opportunity to provide new insight to the project and help guide our progress towards the final goal.