When we think about Agile, we tend to only think about it as method for development projects. Agile at its core is really about ways of working adapting quickly to changing requirements, environments, client requests and new learning.
It is about flexibility, the ability to respond to change and an agency culture where people are encouraged to collaborate and work at the highest level possible. Agile depends on capitalizing the value of the people on the team, to accept and react quickly to change.
As a project manager, the concept can be a little foreign, as being more flexible means lots of change, redoing work, reacting to another change, and so on. That’s not a natural way for traditional project managers to work. Traditional PM’s like things organized and progressing to an end. Working in Agile means that we might not know what the “end” really means or looks like.
When you first introduce Agile into your own team, it’s going to take some time to get use to a different way of working. As project managers, this means that you kind of have to evolve your thinking, learn about new ways of working, and unlearn some other tried and true processes.
Not everyone is going to feel comfortable working in this environment. No more command and control, layers of account peopleand gantt charts. However, working agile does not mean you work without process.
I fully expect that Agile is going to continue to evolve as a project management methodology. When we talk about Agile, we have to be clear that there are two types, “Big Agile” and “Little Agile.” Big Agile is the theory and philosophy of how an organization works to support being Agile. It’s a philosophy that is a way of doing things and the reason for doing them.
“Little agile,” are the tools and techniques and activities that people use to implement Big Agile. These are approaches that sill provide for increased team flexibility, standardized, repeatable guidelines for working, that follow Big Agile thinking.
So when we think about Agile, we are striving to be more flexible, adaptable, quick and resourceful. Little agile are the tools for us to get there.
When we think about Big Agile, we have to think about three large concepts.
The first is the setup for the way of working; working in a dedicated team iteratively and incrementally.
Iterative means that you work in a process that you repeat for similar lengths of time (like 1 or 2 weeks).The size of the project will determine how many increments and for how long. The idea is to get into a rhythm of working so you begin to see results of the work being done instead of at the end of a long phase – for a development project, it could be you work in two week cycles over the course of 3 months, for example.
Incrementally, means that you do one grouping or chunk of work at a time, then with each iteration you add another chunk. At the end of each iteration, the idea is that you have something to show to your client. You do this so that you can get early feedback, make adjustments, test out ideas, or deploy before the end of the project. With each iteration, you add to the project, evolving it over time till you get to a deployable or “end” state.
Dedicated teams are nothing new to creative land, what is different, is that it means that they are really dedicated to the project full-time, rather than working on a bunch of other projects at the same time. Now, we know in agency land, this can be hard to pull off, since we have a tendency to move resources around as needed, because of skill-level or other resource issues. Now, you can still manage teams as a dedicated resource by, keeping all of the related projects with one team. All of the pieces are then prioritized (working with the client to decide).
The big idea is that you work in a dedicated team, and at the end of each iteration, or time period, you have something of value to show the client. In the first time period, the client decides what should get worked on, and with each iteration you add things in the order they are of value (incrementally), and then repeat the process through multiple interactions till the work is done.
The second concept for Big Agile is that change is going to happen and should be embraced.
Again this runs counter to traditional project management thinking. Client makes a change, we produce a change order and charge for it. In a waterfall environment and in an advertising environment, we look to prevent change, since we are always concerned about some form of hard stop date for something that is going to be in some form of media by a specific date.
Embracing change in an advertising environment is freaking scary for people. For development projects, embracing client changes early and adjusting on the fly of what can and can be done before a deployment date can be very impactful. Working with change means that you can make a course direction that can and will make a positive change in outcome. We are also talking about reasonable adjustments here. Because the team is dedicated, embracing change is with the group in a collaborative setting.
Now building a platform and adding and switching features and requirements as you go can seem a lot more manageable than applying agile to large narrative needs. Could you quickly change up a commercial production, with a script and a director, and 3rd party costs under the same scenario? Probably not. However, reacting to, or taking advantage of something that is happening in real time, allows an agile team to react and take advantage of these instances by producing short pieces of content that can be quickly produced.
So planning does play a part in Agile. Your end product may be a Super Bowl commercial, but how you react to market conditions around that air date and take advantage of them are process ways of thinking about embracing opportunity and change.
To protect your agency, from major changes is built into agile. Things are “timbered.” With each iteration, the client and the team prioritize and select the most important work to be done during that iteration. In return for being flexibly at the iteration stage, the client has to agree to no changes during this time. That doesn’t mean their can’t be exceptions. But by working in 1 or 2 week intervals, you can maintain your scope-of-work, because the group can only do so much during that time period. If more work needs to be done than the group can do during the time period, it needs to be pushed to the next iteration.
There are limits to what any team can accomplish during a set time period. Things can go out of scope, and scopes, resources and costs can still change.
The third concept in working Agile means that you are going to have a very close working relationship with your client.
In some agencies, this may even mean a co-location or co-working environment. At the far end of the spectrum, you are working with the client a few times during each iteration, and on the other end, the client is part of the team.
In an agile environment, the client interacts directly with the project team, and attends all meetings.
Traditional briefs, and traditional ways of pre-building requirements and functionality are a bit different in agile. Rather than create a detailed spec sheet, the client presents goals for the team to work on in the form of “user stories.”
Now, your agency may have a significant role on the strategic level for build out what these user stories are. In a nutshell, a user story is a way of describing a part of the project in a way that helps the team understand the end business goal for that specific feature.
For example, a user story might read, “When this hotel reservation feature is abandoned on the reservation page, the user will be prompted to complete to complete the transaction.” The client tells the team what they want the end result to be, but the team fill figure out how this story plays out, gets developed and how the end goal of completing the reservation will happen.
Now the team may work on multiple user stories during an iteration, but at the end of the iteration, the team and the client will show the client how they solved it, prototype it or built the new feature. If it gets approved, then the team is ready to work on other user stories, or if the client doesn’t like the solution, then with input you make the changes during the next iteration.
Showing work early (and in low-fidelity ways) can make decision making faster, it can also uncover technical requirements that may have to be addressed in order to fulfill the execution of the user story.
Now, in an agency environment, where it may not all be development, using the “User Story” method for other projects and putting them into the iteration queue is an agile way of accomplish all sorts of other creative non-development work.