Back some 15 years ago when I first entered into the creative agency world as a Project Manager, I was taught how to manage and lead projects in a traditional and linear way. Each team member, each discipline, and every contributor had their place along the project path. Once the strategist was done setting the big picture, it was handed over to the creatives, once the creatives were done, production was brought in (dating myself again, these were days of a lot more print) so on and so forth. There were the internal presentations and reviews, iterations and press checks, but projects generally all followed the same process. Hey… it worked at the time, or so I thought.
Fast forward to this last July when I joined forces with Portent to head up the Creative Services group. I’d heard of the Agile approach to projects along with other approaches like Waterfall, but never tried them.
Agile at Portent
Recently Portent had the opportunity to partner with a client to design and develop a website to support a new brand. Of course, the project had to be completed in a very short amount of time, in complete secrecy, oh… and and it had to come out of the gate looking like a brand that had been around for a while; one with street cred.
It was our internal team for this project (in this case, one designer and one developer) who introduced me to the power of Agile development. Because of our crazy fast timeline, we realized we needed a method that proved to work quickly, blur the lines for organized phases, and encouraged incremental and iterative approaches.
Okay, so what is Agile?
Agile is a pretty new player to the production game, but it has made substantial gains in use and popularity within the last couple of years. With the Agile method, there is not necessarily a pre-determined course of action or plan. Rather, designers and developers are free to respond to changes in requirements as they arise and make changes as the project progresses.
Purely linear project management doesn’t account for different perspectives working on the same outcome. Things change as the project cycles through different teams, and Agile accounts for those changes as they happen. That way, everyone is on the same page and can agree that the finished project is the best version possible from all angles.
Agile requires two things: That each team member has access to each other at all times (best case scenario being that everyone is in a room, working together), and that the team is able to work together well. If your team is not cohesive, Agile won’t work.
Method to the Madness
For the Portent project, my designer and developer worked together in a small private office, day after day, late into many nights. Great design was concepted, development was able to contribute and weigh in, the two would volley innovative and cutting edge development practices and how that could compliment great design. It was this rapid back and forth from both experts that resulted in an amazing website and experience.
So really, when it comes to choosing a method or approach, there is not a right or wrong choice. You just need to understand which method is better suited to your project and your needs. Clearly for this opportunity, the Agile method was the right choice.
So what resulted from the project? It’s almost public. Please check back Nov 20th to see for yourself.