We have all heard of the term ‘agile’.

Agility can be defined as ‘an ability to move quickly and easily’. Also the ability to think and understand with speed.

To have ‘agility’ and be ‘agile’ is considered a good characteristic.

What does ‘agile’ mean when applied to the big wide world of digital? And what does it mean for digital agencies?

Birth of agile

Agile was applied to software development way back in the spring of 2000 when leading members of the agile community came together to discuss and formalise methods of working.

This led to the creation of the Agile Manifesto in 2000, rooted in the desire to become more adaptive and to deliver a better, more valuable software product.

The founders signed up to the following four statements:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The agile approach has developed since those days but still holds true to these initial values and philosophy.

Scrum

These days the word Scrum is often heard when talking about agile methodologies.

It’s the most popular framework within teams developing software products and has various defined roles including scrum master and product owner.

Scrum teams work in set time periods called ‘sprints’, usually around 2 – 4 weeks long, which aim to deliver agreed product features.

Scrum is part of the world of ‘agile’, a specific set of guiding principles and tools for product development. But, there is a much bigger picture here to consider.

For example, software teams working in sprints may not actually be agile!

But, let’s not get lost down the rabbit hole of Scrum, which is a specialist approach and broaden our minds.

The agile agency

We need to go back to the root meaning of the word ‘agile’ here.

What can we learn, absorb and apply to the world of the digital agency, which works in a very different way to that of an internal software development team?

Agencies have clients and have a much wider range of activity than web or software development.

Yes, creative agencies will develop websites and other technical solutions. But, they will also be managing print output, developing video solutions, creating social media campaigns and producing monthly reports.

The team roles here are more varied and there will be a mix between varied project work and ongoing monthly marketing optimisation and evolution.

The client

Each client and each client’s business will vary much more in an agency environment.

There will be more dependencies on the client-side and these can be challenging to manage.

In an agency world, clients may not be as educated on the meaning of agile or be very accepting of the language, methods and ideas presented.

How can an agency be more agile?

The language

First of all, everyone needs to know what everything means!

Both client and agency need to speak the same language. This is an important starting point.

Agency roles

Within a clearly defined smaller project, responsibility should be shared throughout the team and not placed in a single project manager.

This means adopting roles such as the product owner and team manager (scrum master) alongside the development/design team and external stakeholders (the client).

Pulling not pushing

Project tasks should be adopted by each member of the development or design team using a pull mentality rather than being foisted upon them by a single project manager.

This encourages responsibility and ownership.

It also encourages team spirit and means that time estimation can be more accurate, plus task completion more efficient.

For this to work teams need to be stable and able to take on responsibility.

Throw out the massive ‘fully scoped’ project plans!

How often have you viewed a massive Gantt chart with each project stage fully scoped and timed to fit in with the next one?

How often have you thought, “well, I bet that doesn’t work out.” Then, halfway into the first stage of the project, the client has thrown in a curveball, which dishevels the original plan.

Or, through some initial development work, the dev team were able to suggest a different approach for the product?

Probably too often to count.

In an agency environment, large waterfall type project plans very often fail. It’s often impossible to estimate a reliable completion date or even a reliable project cost.

Finally, the actual product itself could change scope a number of times. This is a good thing and leads to better digital products being delivered.

Bring in agile proposals!

To fit in with agile ways of working, agile business proposals are required.

The new business team needs to work with the delivery team on creating any agile proposal.

This is so that there is no disconnect between what is proposed and what is achievable in delivery.

It also fosters responsibility and ownership across all team members.

In an agile proposal, the ‘product’, whatever that is – a website, a mobile app, a piece of interior design – is NOT completely set in stone at the outset.

Why is this?

• A client will often not know exactly what he or she wants at the beginning. Often the client might have an idea of what’s required but will need some education into what will work and what won’t.
• The client will benefit from ongoing feedback from the agency during the early stages of a project, which could seriously change the project scope.
• Early user testing could reveal that there are problems with the product USP. Early user testing is important to make the right path is taken.
• Market conditions could change which require a change in direction. This is an external factor outside of the project control.
• A competitor could alter its path, therefore, requiring a re-think. The same as above. An outside factor which could change the way a product or service is developed and pitched to the market.

The full requirements of a product, the price and the delivery date should not be set in a proposal.

Of course, there isn’t a single client that would want to work to completely open-ended contract either.

Therefore, a product proposal should be broken down into smaller chunks, in line with how they would be delivered. The development team should be involved here.

Only the first phase should be estimated based on the initial product outline. The further phases should be sketched in lightly as ‘predicted’.

The agency should bill for work completed during the first phase. Then the second phase, including any requirements changes can be estimated.

Again the agency bills for time and work completed.

The best possible product…

In this way, the client gets the best possible product, rather than something built on poorly thought out initial business requirements.

Client and agency are able to work together as a team, with respect, to educate and evolve their relationship towards creating a much more valuable product.