Why Agency Agile Is Broken

Countless books have talked about why organisations need to adopt an agile way of working; the promise of delivering value faster and ensuring that the customer ultimately gets what they want because they can change their mind and reprioritise requirements is an alluring prospect.

Unfortunately introducing an Agile way of working within an agency often results in unmet expectations and a feeling that Agile didn’t deliver everything that was promised.

Let us explore a typical “Agile Project” within an Agency.

Meet Chris (the sales person). Chris is really pleased that he has a lead from a new company and feels confident the agency can deliver the work required.

The project starts well — the client comes into the office and explains their requirements. Chris invites Joe (Technical Expert) into the room to assist with the sales process; Joe listens carefully to what the client says and articulates confidence that he understands exactly what the client is looking for.

In some agencies a project discovery phase may be sold to the client — this is usually a meeting or series of meetings which allow Joe and his friends to drill into what it is the client actually wants and ensure that they have a really good grasp of the requirements for the project.

At some stage during the sales process Chris will explain to the client how the project process works and the client is introduced to the concept of an Agile delivery. Invariably the conversation will go one of two ways:

Time and Materials

The agency explains to the client that they work in an Agile way and as a result the client can change their mind and re-prioritise requirements as the project progresses. For this reason the agency can’t give a fixed price and instead will estimate each of the requirements based upon the number of days required to complete the work.

The client is asked to place a work order for a fixed number of days to be used to deliver the highest priority requirements. If the client adds additional requirements they will be estimated and then prioritised accordingly. This might mean that lower priority requirements can’t be done because the client hasn’t purchased enough days — the client can either forego the requirement or purchase additional days to get the work done.

The client signs up to this approach confident that they are in control and that they effectively have a fixed price because they know that they won’t add or change any of the requirements during the project.

Team Velocity

The agency explains to the client that they work in an agile way. The agency has a SCRUM team available to complete work and the team is able to deliver x points of value per sprint.

Each requirement will be estimated according to size and this will be converted into a numerical value using the Fibonacci sequence (a significant amount of the meeting is spent explaining this concept to the client). It is agreed that requirements will be prioritised by the client and will be grouped together into a sprints worth of value.

The client is asked to place an order for a set number of sprints worth of work. If the client adds additional requirements they will be prioritised outside of the current sprint. This protects the work currently being done by the agency and ensures that the entirety of the clients budget isn’t wasted by going down one particular route without checking in with the client.

The client signs up to this approach confident that they are in control and that the overall project budget is protected. The project is effectively fixed price because the client knows they won’t add any further requirements and there are milestones in place at the end of each sprint that can be used by the client to check progress.

Following this initial meeting the company will undoubtedly want to produce a proposal. In this document the company will replay what they have been told by the client to provide confidence that the requirements have been understood. The client will sign on the dotted line and the project will begin.

Typically the project starts well; delivery seems to be on track and the developers make all of the right noises during daily stand-ups (The Agency has started doing these because that’s what Agile organisations do — in reality it is an opportunity for the Project Manager, Jim, to demand an update which can be given to the client).

The client is given regular updates by Jim (who may or may not have been involved in the discovery phase) and they are pleased things seem to be on track and progressing according to plan. As the project progresses things start to go wrong:

Something was under estimated

A specific requirement was estimated as a small task that should only take a day to do — this isn’t actually a small task and takes 8 days to complete. At the end of the sprint the client isn’t happy that everything which was promised hasn’t been delivered within the agreed timescale.

Jim explains to the client that the feature took longer to do than expected and advises that the work will be prioritised in the next sprint. The client asks who is paying for the next sprint and states that they shouldn’t have to because the estimation is at fault and states that Chris promised that the company were really good at estimating — in the clients view as the agency was responsible for estimation it is the agencies mistake and as a result the work that was not completed should now be finished for free.

In return the client will graciously accept that the deadline has slipped but advises it is now critical that no other deadlines are missed or their project will be severely impacted.

In case you hadn’t noticed — the concept of Agile is now forgotten and we are effectively working fixed price waterfall.

Another project is experiencing problems

The clients project is underway and progressing well. Another project is experiencing some issues (perhaps it is the project referred to above where something was under estimated) the developers are asked by Jim to help get the other project over the line and immediately stop work on the clients project.

At the end of the sprint everyone is surprised that the clients project hasn’t made as much progress as was expected; Jim explains the problem to the client and the agency agrees to continue working on the project at no extra cost to get the work over the line. The client accepts that the deadline has slipped but advises it is now critical that no other deadlines are missed or their project will be severely impacted.

Once again we have slipped into a fixed price waterfall mindset.

The scenarios described above may be repeated several times. By the end of the project the client is generally ‘happy’ that they have a deliverable that broadly meets the requirements that was originally outlined. It is likely they have a sense that they have had to compromise on some features but they accept this as they have worked in an agile way and this was explained to them at the outset. The project has taken longer to deliver than anyone thought it would but the client is happy because they have only had to pay for the work that they committed to so their budget remains intact.

If any additional money has been spent it is for something brand new that definitely wasn’t mentioned in the initial project meeting. We know this because even though the client was “absolutely sure” that it was mentioned in the meeting the agency has spent several hours going through the proposal internally and grilling everyone who was at the meeting asking them to remember what happened in the room several months ago just in case the client had mentioned the new thing in passing.

After much negotiation the client reluctantly accepts that it was not part of the original requirements and agrees to pay for the bare minimum amount of extra work in order to make sure the new thing gets done.

Sound familiar? I have seen the project process above repeated within countless agencies. The harsh truth is that although everyone involved in the process firmly believes that they are working in an agile way the process described above can at best be described as “fr-agile”.

The agency has taken the bits of agile that sound good to the client and have sold a dream of being able to change requirements and deliver things quickly without also ensuring that the client is subscribed to the reality that they are also working in a world of estimation uncertainty. As a result the agency has inadvertently taken on the uncertainty risk because when things go wrong the agency gives ground in order to make sure the client is a happy customer.

Fixing Project Variables isn’t Agile.

The starting point for fixing the problem is to understand why the approach outlined isn’t agile. Let us consider a waterfall project — in projects of this type organisations try to fix the 3 project variables:

• Time
• Scope
• Budget

Agile methodologies recognise that in order to adapt to change all 3 of these variables cannot be fixed. In an agile approach typically budget and time will be fixed by virtue of the fact you have a set number of resources working for a given period of time, i.e. a sprint.

Agile methodologies recognise that in such circumstances it is not possible to fix scope because of the degree of uncertainty found within software development projects.

If we map this onto our typical “Agile Project” it becomes clear that the clients expectations were mis-set during the initial project meeting — estimating features in terms of days or story points allows the client to build a phycological bond between the money they are paying and the estimation that has been given — it is this phycological contract which is broken when a piece of work has been under-estimated and delivery therefore takes longer or when less work is delivered that was originally promised.

A better way ….

In order to move beyond fr-agile ways of working clients and agencies need to embrace the true essence of what it means to be Agile.

A good starting point is to review the Agile Manifesto. The first statement is that a truly agile organisation values

“Individual and Interactions over processes and tools.”

In my view the solution the agency agile problem requires agencies and clients to establish a close and trusting bond where both agency and client are incentivised to do the right thing and work together in order to meet the objectives of the engagement.

For an agile project to be successful the whole team need to work truly as one organisation. Both sharing in both the successes and failures of decisions that are taken.

Agencies must build a bond with a client where we move away from a traditional customer supplier relationship and move to a world where the everyone is aligned and incentivised to achieve the same goals and ambitions. This requires both parties to truly embrace moving beyond a fixed scope agreement and understanding at a deep and meaningful level what success really looks like.

The solution to the problems highlighted in this article are not easy or straightforward; but solving a problem begins by identifying that there is an underlying issue and agreeing that there is a problem which needs to be solved.

The premise of this article is that Agency Agile is broken; what are your views? Have you encountered an agency that faces the problems outlined in this article? Perhaps you have worked with an agency who has been able to move beyond the problem and create an environment where both client and agency successfully partner to create a shared outcome, shared risk and shared reward engagement?

Please reach out to me and share your experiences — @Steve Westgarth