Depending on what your agency does, you may or may not be working in an Agile environment. The processes that you use in your agency are really dependent on the way your team chooses to work. One of the reasons why people are gravitate towards Agile or working with agile methodologies is because there is a belief that working in Agile means that stuff gets done (and delivered) faster.
That’s partially true — some agencies struggle in delivering large projects, and agile has a leg up when it comes to organizing. Here’s the thing, it is not always easy to change the way creative is done in agencies, especially moving from traditional PMs and Account Managers to an Agile framework. For one, advertising projects often has hard deadlines and fixed sign-offs. And the benefits of agile aren't so beneficial. The second problem is that Agile depends on a different type of project management — moving away from single sources of managing a project to shared accountability and self-directed teams.
However...
It is perfectly okay to blend agile with other agile-like thinking and processes to get to a place that works.
How we work at the beginning of a project, and helping define the actual challenge, is a good place to start. For example, we can look to Design Thinking methodologies to help us define, learn, engage with multi-discipline thinking, using observation and empathy to help us form insights, ideate on opportunities and frame what the actual opportunity is.
It’s also okay to run certain projects as Waterfall and not Agile. Agile and Waterfall processes can seem like they are completely opposite ends of the spectrum. They certainly are very different ways of working, with two very different sets of beliefs in the way to work. However, many creative shops have already had experience working in an Agile way, even if they didn’t know it. (Small Teams! Yeah!)
Think about how we form teams to tackle creative pitches for new business. The pitch team is typically put together with people from all different agency disciplines working to the same deliverable. The concept of working in Agile isn’t new. Think about how fast your agency has had to work to pull off a pitch, and what they delivered during that time period. Ever had an “all-hands-on-deck” situation where everyone needed to come together to figure out a client emergency? Things get done, because everyone collaborates.
Merging all of these processes together is not a simple task.
Design Thinking and the concepts surrounding idea factories are easier to match up to Agile processes since at the core, they are very collaborative processes. Mixing Waterfall and Agile is much more difficult, because they require different mindsets. Waterfall is a planned out process that has a harder time reacting to change than agile. Waterfall phases versus the goal of Agile timeboxes (sprints/scrums) produce results differently.
Training is vital to implementing Agile in an agency.
You can’t stick a project manager who has never run Agile and assign them a project without any training or instructions on how to assign stories, scope agile or plan sprints. You can’t stick a scum master from a software company into a creative agency and ask them to manage a commercial production or deal with your client’s procurement department. You can’t always force fit some projects (and people) into two different ways of working.
Different ways of estimating projects.
Scoping projects in Agile require a methodology of contract writing that is very different to waterfall breakdown of costs. Story points don’t always match one hour or one day of work the same way you would charge for an hour in a traditional estimate. That’s not to say clients don’t get on board with agile scoping costs. Once you get them to start thinking about point values that take up the available time in the allocated sprints, its pretty easy to stay in scope. On the financial side, you can certainly look at how story-points translate internally to hours, but comparing metrics between agile and waterfall are going to be different.
In a waterfall project, if you complete a project earlier or with cheaper resources you get a higher profit margin, or if your project runs into trouble it can be very easy to go over budget and hours. In an Agile project, where you are working with a set number of story points to complete for each set sprint, you are working with a fixed team to a fixed set of points. This means your team is dedicated to the project for a specific length of time. The benefit and the downside is that your available resource costs are tied directly into a more fixed profit margin for a fixed period of time.
If we are looking to add Agile into the agency that is use to traditional project management, we’ve learned that it takes reshaping a number of factors. We’ve learned that you need a number of shifts in thinking on how you shape your agency culture, your agency processes and on developing self-organizing teams.
We’ve also learned that it requires a strong commitment at levels in the agency, from leadership to staff to establishing new relationships with clients. We know that we can start small with one pilot team, working in a multi-disciplined fashion, and that digital projects or product development are the easiest to start.
Moving beyond interactive projects to include other types of marketing into agile is a little trickier. It is going to require a bit of training, reorganizing, and coaching. We also have to teach our new team members new terminology and the meanings of some of the basic concepts around working agile-like.
For a creative person coming into an agile environment, who has never worked this way before it can be a bit confusing, but the goals of working agile are meant to be empowering by allowing teams to collaborate more and have the ability and authority to make quick decisions about a project’s direction, the way things get done and in what order.
The biggest concept to overcome is that the entire team is working together to as quickly as possible come up with a minimum viable product. That you have something to show, get a reaction to, and then build upon. Earlier in this section we talked about as giving up the big reveal.
So let’s review how agile works and compare a bit on how we can add in none-development work. Agile requires us to break down work into “stories” which are chunks of larger projects (like functionality in software) or ad-hoc requests, like bug fixes. Each story tells the team what needs to be created. Together, the team assigns the story points (or hour) they think it will take to complete the story. Agile teams work in sprints, periods of time, perhaps one or two weeks in which they can break up their time to tackle the story list. Since each week only has a set number of hours (which include review time) there are only a certain amount of stories that can be worked on for each sprint.
Stories are prioritized, through what they call a backlog. Stories chosen for the sprints are placed on a burn-down chart, where everyone can see them move from incomplete to approval to complete.
Agile can take all sorts of projects into its sprints of all sizes, you just need to have a process that can handle these requests.
