The Benefits of the Agile Process - Digital Advertising Agency – Marketing Strategy | IQ Agency The Benefits of the Agile Process
avatar
  • 03.04.14

The Benefits of the Agile Process

Clients love Agile agencies

In my last post I discussed what Agile and Scrum are, how they can work at an agency, and the 4 top reasons our clients tell us they value working in an Agile way.  Today I want to dive a little deeper into an example of how Agile is flexible, and saves clients time and money.

Many agencies that have moved to Agile claim productivity increases. I’ve seen everything from 25% to 600%!  Of course, a lot depends on how dysfunctional the delivery method was in the first place.

What we do know (and have good data for) is the consistent failure of the traditional waterfall or spiral methods to achieve success, especially with complex engagements.  Since this describes practically all projects that a modern agency is called on to deliver, you can see the problem. We believe the answer is Agile.

At IQ, we had the opportunity to compare the performance of traditional and Agile methods in creating a website for a client. The first version we built using traditional methods and then sometime later we redesigned it using Agile. The results were astonishing.

Agile saved the client over 25% in cost and launched the project 2 months quicker than the previous site. Compared side by side, there was an amazing 75% improvement in both the cost and time to implement.  Equally important the client enjoyed the process and felt they were actually a true partner instead of an adversary.

Let’s take a look at a few specific elements of what happened:

1. Can you get me something earlier for my conference?

There is always something around the corner like a big dealer conference, or a meeting with your CEO.  In both instances we got the question: “Can you get me something quickly to show our progress?”

With the traditional delivery method, all we had was a series of wireframes with arrows and descriptions, plus a static image of what the home page might look like.  That was because the project team wasn’t at the design phase yet. It wasn’t very inspiring and was tough for those with little imagination.

Contrast that with Agile’s iterative method where we get a working prototype every two weeks.  We didn’t have to make anything special, because we already had something ready to go.  The presentation of the working home page drew “oohs” and “ahhs,” our client was a hero and no one questioned our progress.

Strangely, with both methods we were actually at about the same percent complete, but by changing from the assembly line method to Agile, reality really shifted.

2. I just saw this new thing and we gotta have it.

Change is inevitable in any project. At some point you want to make a change because you see something that was hard to know at the beginning.

I used to consider this dreaded “scope creep,” which always resulted in requirements meetings, reviews of the SOW, days of arguing over the scope, more meetings, lost time, hard feelings, and often three steps back to rework previous phases.

What a waste of time and money, and aggravating for a client, who just wanted to make the final product better.

Now, as an Agile agency, we look at ideas as a blessing and even encourage them. In fact, often the most difficult thing is to get our client to understand that they can come up with ideas and get them realized whenever they want.

The client in this case, for example, had the good idea, late in the game, to add some localization.  With Agile it was easy. We moved it into the very next sprint and two weeks later — there it was.   No push back, no forms, no negotiation, just delivering what the client wanted, when they wanted it.

These are just two examples from one project, and there were many more on this project alone. They demonstrate that Agile is flexible, and saves time and money as a result.

Interestingly, however, I have found that it’s the removal of stress, and the shift from an adversarial client/agency relationship, to one of true partnership, that clients notice and value most.

You may also like:

Content Strategy: 7 Steps for a Better Voice & Tone

UX Design: My Favorite Features Aren’t Features

Innovation and Data – The Marketer’s Dilemma

Want to know more about IQ? Contact Us


  • avatar
    David Says:

    Hi Steve! Thanks for the post. Our agency has also using a variant of Agile for many of our projects although not all clients and projects seem to lend themselves to this. I wanted to ask how you handle two quirks of Agile that we have trouble reconciling with realities of our work:

    1) Design is not agile – If our designers were layout out a mobile app, they don’t cut a design that has one sprint’s worth of features. Rather, they design the finished app. Developer sprints tend to slowly “fill-in” the app with features until it looks more or less like the design. This seems un-agile but the alternatives seem unworkable (e.g. partial design that is iterated or redoing the full design at the start of each sprint). How do you handle this?

    2)Budget and schedule are fixed – Agile seems predicated on the idea that sprints could go on indefinitely and was born in product companies where the product can be continually refined. Our clients frequently come to us with a fixed budget and schedule (restricting us to accomplish project goals in a fixed number of sprints). In parallel with this, the client often has a minimum feature set in mind as well. We usually have to put aside Agile’s philosophy of not doing deep estimation and planning beyond the current sprint in order to be able to give the client assurances that their project goals are achievable on their time and budget. After that, while we are working in sprints, in many ways we are actually racing against a typical overall feature-budget challenge. How do you handle this situation?

    Regards,
    David

    • 04.15.14
    • 12:52 pm

Leave a Comment

* Denotes required field. Your email address will not be published or shared.