Exploring agile development for digital marketing
When I read Sue Spaight’s post from SxSW – Agencies need to think and act more like software companies, my interest was piqued with the mention of agile development. I’m sure there are many ways that agencies could benefit from adopting some practices of leading product/software development companies, but as an interactive project manager, I am particularly interested in this one way. I began to wonder: What are the specifics of agile development and what makes it unique? Do I agree that an integrated marketing agency would be better off if we embraced agile for our web and mobile development projects? How would we apply it if we wanted to?
I am in no way an expert in agile project management or product development. I can admit to knowing of it, but I’ve had no training in it. What I learned about agile in preparation for this post is that I have a lot more to learn! I also learned that we’re not going to just say “let’s do agile” for that project that’s kicking off tomorrow. I’m just going to go ahead and declare a series right now – including perhaps a book review or two.
But I do feel confident enough to introduce the basics and to start to build a case (in one way or another) around whether this development method – created to transform software development – would enhance the way an agency brings digital marketing initiatives to life.
First of all, agile is not a single thing, but rather a set of beliefs. There are a variety of different disciplines under the agile umbrella – Extreme Programming, Adaptive Software Development, Feature-Driven Development and Scrum are a few examples.
While the concepts had been brewing since the late 1950s and evolved through the 1990s, agile was officially established in 2001 when a group of software developers drafted the Agile Manifesto. Yes, a manifesto. I love that. I do really think this makes it a good fit for agencies already. Agencies love manifestos – especially when they are short, smart and just a tad condescending (reow!) Here it is:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The last sentence of the Manifesto is really key and should not be overlooked. agile is often seen as a competitor to traditional/waterfall development approaches – and it is! (You would use one vs. the other.) But when it comes to a disciplined approach to deliver a project (or product) on time and on budget, they are family and the blood runs thick.
In a nutshell, waterfall management involves a sequential path of phases led by a planning and requirements-gathering phase that carries significant weight. Since I love an analogy, I’ll say that this method is like attempting to pack every possible item of clothing into the suitcase for a big vacation. You don’t want to leave anything behind and you want to be prepared when you get there – because it’s hard to come back home to retrieve a missing item and you don’t want to buy it at your destination because it will be too expensive. So you do your best to lay everything out on your bed, create outfits, make lists, buy new resort wear, negotiate between shoes, roll the items to reduce bulk, etc.
(Back to our real projects) We do our best to define and predict everything up front with the ever-elusive promise that the better we do this, the more successful our projects will be. And then, when our projects (or development cycle) goes haywire again(ugh, I didn’t know I’d need my earmuffs in Florida, damn this cold snap) we blame ourselves for bad planning or, often times, the CLIENT for changing requirements. This can cause stress and, frankly, sadness. The more predictable the circumstances are and the fewer the unknown risks; the more chance waterfall development has for success.
Contrary to traditional (which values “knowns”), I believe it is accurate to say that agile values “unknowns” – when executed effectively, it is change tolerant. It allows the recognition that the project itself exists within an emergent environment. While the project is in motion, the rest of the world doesn’t stop – technology is changing, consumers are changing.
Back to packing for the vacation, agile is like saying, “let’s just take a carry-on and see if that will be enough.” But we aren’t careless about it – it certainly requires prioritization. I’ll get more value from these sandals than these boots. I’ll get morevalue from this swim suit than this box of Triscuits. And I absolutely can’t gowithout my ID – so I’ll make sure that gets in the bag first. Got it? This method of packing gets you to your destination quicker, but it might be an unacceptable vacation due to the things you left behind (Bummer! No sunscreen, can’t go to the beach!) But since you got there quicker, you still have time to go back home, pick up the things you need and return. In fact, since you’ve been to the destination once before you also have the opportunity to alter the destination altogether – equipped with your more-informed baggage.
In similar fashion, the agile team would get together and prioritize a list the known requirements. They would then take a chunk off the top of that list and complete a full development cycle (1-4 weeks) to deliver a functioning product that meets the highest priority needs. It is then determined whether this can be reviewed by the client, put into live testing or even released as a finished product. If it is not released, they return to the list (which can be changed and re-prioritized) and repeat the process until they have a functioning product that is ready to bring appreciative value to the client and the market.
So, in consideration of the presentation at SxSW – with rapidly changing technology platforms, desire to innovate, pressure to create a user experience that has never been built before. There does seem to be validity to a claim that a traditional development approach may weigh an agency down (not to mention the $50/checked bag fee).
It definitely inspires me to learn more. I have a lot of questions still regarding actual application. How do we estimate within agile? How much impact would our clients feel? How would our organizational structure need to change (if at all) in order to facilitate an agile work flow? Who in our industry is doing this well?
I’ll attempt to answer some of these questions for myself and for you in my next post. If you have answers, or feedback, or thoughts, let’s hear them. In the meantime, it’s back to this requirements doc – I just need to make sure it’s perfect before…