Anyone who has worked in a digital agency is well aware that change is often the cause of missed deadlines and, in turn, unhappy clients. Whether this manifests itself as scope creep, shifting deadlines or staff turnover, the success of your project will almost certainly depend on how effectively your team can respond to all of the elements around you that are in flux.

Adopting techniques straight out of an Agile textbook might seem an obvious first step. You will find, among other suggestions present in the Agile Manifesto, advice like this:

‘Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.’

In reality, it takes time and considerable trial and error to figure out what works and what doesn’t. We are continuously on this journey at Ostmodern; as someone who had only worked with in-house products before joining the Skylark implementation team, I learned a lot along the way.

I’ve listed out some of these learnings below, but will close this introduction with a crucial warning: being Agile is NOT about following a prescriptive formula.

To use my favourite analogy, these are merely tools in a box; the real skill lies in choosing the right ones for the job at hand.

1. Re-estimating is part of the journey

Estimates are never final until the work is done. Re-estimate, then re-estimate again!

Let’s face it, no-one likes to estimate work, especially early on in a product’s lifecycle when concrete requirements are sparse, designs thin on the ground, and you’re not even sure the feature in question is going to be built.

It can be tempting, once you’ve battled through and extracted satisfactory estimates from your team, to send these off to the project manager, or to the client, and breathe a sigh of relief knowing you never have to go through this experience again.

At some point, however, you’re probably going to be held to these estimates — and, as we know, things change. Designs will change and requirements will change. Even if they don’t, what you and your team know about what you’re building and how you’ll build it will change as you progress through a piece of work.

Instead of being held to these rough guesses at how long each feature will take, take the time throughout a project to re-estimate your deliverables. This will allow you to re-plan the work and manage expectations at the earliest possible opportunity, taking pressure off the team and hopefully avoiding late nights too close to a deadline.

2. Regular releases will save you time

Release as often as possible, both during initial delivery AND once a product is live.

Everyone can agree that getting working software into the hands of customers as early as possible is invaluable — whether the customer in question is the client, an end user, or hopefully both — in order to obtain the most useful feedback possible. Early delivery is the best way to help manage expectations and show the value you’re adding to the product by way of progress.

There are also other benefits to releasing as regularly as possible.The more regularly you wish to release new code, the more reliable your release process should be.

If anything goes wrong, or if releasing takes too long — fix it. By tuning your release process you will end up with a very low-risk, inexpensive process. Maybe you’ll even end up with a Continuous Deployment pipeline.

Either way, less time mopping up releases and fixing production issues means more time to work on delivering a valuable product — something both you and your clients will appreciate.

It’s also important to keep your in-life software up-to-date. Consider this scenario: you launch a product for a customer who is yet to agree their support contract or any continuing engagement.

Their software is running well, so is left alone for weeks, months, maybe years. One day, you receive an email from your account manager: ‘We need to add some new features to that product.’ By the time this happens, the codebase is so hopelessly outdated that any new features are going to come at a cost — libraries need updating, security vulnerabilities have to be fixed, your deployment pipeline has broken, among others.

All this can be avoided by periodically spending a small amount of time updating the project. Once again, the more you do this, the less effort will be required in each update.

3. Happy teams are more effective

The subject of high staff turnover in creative agencies is a familiar one, which has been analysed to the nth degree. The loss of domain knowledge when people leave an organisation can come at a significant cost, especially if their focus has been on delivery rather than documentation and knowledge sharing.

When you’re facing an imminent deadline and the client is asking why you haven’t delivered their product yet, a tempting fix may be to encourage your team to work late, come in early and work the odd weekend. No matter how much this strategy appears to increase productivity in the short term, its long-term impact is indefensible.

Extreme Programming (XP), supports the concept of a 40-hour working week. Maintaining a consistent working pattern helps your team deliver more predictably, prevents them from burning out and helps ensure that their output doesn’t suffer as a consequence of working unsociable hours.

This saves time otherwise spent re-working dodgy code that was written with bleary eyes during an all-nighter, while keeping a team happy, energised and motivated.

Creating a good working dynamic between team members is another factor that is often overlooked. Teams that trust each other tend to make better decisions. Fostering a culture of debate and innovation stems from this trust. If the people in your team are friends, they will also be less likely to move onto pastures new.

Whilst a lot of thought should be put into the hiring process — hiring people that are an excellent cultural fit as well as proficient in their field is imperative — it is also important that you find other ways to encourage teams to bond.

For example, ensuring that all team members working on a project are sitting close together. Pair programming, as another example, can inspire people to get to know each other’s coding styles as well as their personalities.

4. Delegating tasks can have negative results

Resist the urge to plan who works on what when

When a project’s budget has been whittled down during pre-sales, it’s really important to keep track of spending and look ahead at the remaining features to plan how you’re going to use what remains of the pot.

A common response to this, especially for project managers more used to Waterfall than to Agile, can be to allocate work for each team member ahead of time. This ‘push principle’, as it is called, has several disadvantages:

• It is easy to assign one team member to the delivery of all requirements for a feature. This means that everyone else in the team will have little or no knowledge of that part of the product and codebase, making them a single point of failure for the project. Better keep them away from buses!
• Often, the person in charge of allocating work lacks the knowledge to decide who is best placed to do a particular job, instead assuming everyone is equally capable of completing each task. This will almost always result in team members becoming either overloaded or under-worked, instead of working precisely to their capability.
• The reduced autonomy and increase of perceived micro-management can have an adverse effect on morale, and will prevent people from building trust in each other.

By using XP’s ‘pull principle’ — allowing the team to decide who is best to pick up any given task — instead of the opposing ‘push principle’, teams become more efficient and trusting of each other, removing any single points of failure in the project.

5. Collaborate closely but carefully with clients

The Agile Manifesto values customer collaboration over contract negotiation, so you should put the delivery team and the client together as much as possible, right? Not quite.

Of course, hearing good feedback directly from clients can be rewarding for the team, motivating them to continue delivering a high quality product; but you must temper this relationship a little.

If a client begins to exert unreasonable pressure over a team, or unfairly criticises their output, then the team should be removed from this conversation and have someone get the message through to them instead.

Keep these two points in mind:

• Delivery teams should hear feedback directly — especially praise from the source;
• If a relationship becomes more testing, temper this relationship and consider how the team may be shielded.

6. A cross-functional team advances faster

Because of the ebbs and flows of work at an agency, bottlenecks can build up quickly. Developers are idle for days waiting for a Dev Ops Engineer to create the infrastructure required to deploy a project, then suddenly let loose; then before you know it your QA people are overwhelmed by the work accumulated in their QA column now that the developers can deploy and verify their code.

The project is delayed because of the infrastructure lead time; developers are blocked on starting work that has to be delivered sequentially after the items stuck in QA get merged. The result is a withering budget for a project that you are now set to deliver weeks late.

Encouraging your team members to chip in on whatever is required regardless of whether or not it fits with their technical discipline can help resolve bottlenecks quickly. Developers testing each other’s features to help out a swamped QA person not only prevents further work from being added to the QA column, but also helps get through that backlog faster.

Removing bottlenecks is great; preventing them in the first place is even better. Completing tasks simultaneously rather than working on them in sequence prevents a buildup of work in a particular part of a team’s workflow. Examples of this include QA people (or developers) writing automated tests while a feature is being developed; peer reviewing code as it is being written, or designing parts of a feature as it is being built.

Doing this makes you more likely to end up with 80% of the work you’ve committed to being 100% complete, rather than 100% of it being 80% complete, delivering more value to users sooner.

7. Documentation prevents future issues

Supporting a product you build for some time after it’s completed is a common practice. With so many new projects coming in to the agency, the turnover on project teams can be relatively high.

In an environment where it is essential to keep unpredicted spending down, facing unforeseen support costs can mean the difference between a healthy margin and a loss.

By documenting your new product as it is being built, you ensure that whoever has to pick up an unfamiliar codebase to fix any support issues can do so as quickly, painlessly and cheaply as possible. Simple.

The seven tips above are by no means an exhaustive list. Each team is different, and client needs can vary dramatically from project to project. Don’t be afraid to try new techniques and ideas — changing your own approach can help deliver surprising results.

Perhaps the most important advice is this: don’t be afraid to fail. We learn much more from failing than by getting something right the first time.

As long as you’re acknowledging what works and what doesn’t, and sharing this information with your peers and clients, you can rest assured that you’re improving the team’s output, and building better products as a result.

Article by Aaron Ford