What is a consultant to do? Here we have a new client with pockets full of lovely cash and then the dreaded query comes out – “I expect you will running this in an agile manner?”

Sheesh. The immediate response you would like to make is – “Yes of course, just sign over the magical pot of gold that never empties here, and we can start immediately. The project should be complete on the 27th of mumble mumble”

Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

Ok, so to any agency with a fixed time or money budget, a.k.a. all agencies doing any digital work, this spells disaster in the making. Not because it can’t be done from the team perspective, I don’t know a single developer who wouldn’t love to jump on a truly agile project. No, it’s the clients we fear. Agreeing, disagreeing, sending things back, changing their minds, Lions and tigers and bears, Oh my.

As a purist concept, Agile cannot fit within the realms of a fixed budget with any guarantee of delivery. Equally, it cannot fit into constrained time budgets with any guarantee of delivery. So why, oh why are we still working under the illusion that our process is agile, just because the client attended a half a day seminar on the subject.

What we do need is better terminology, to describe the best way forward given time and money constraints, to deliver a story generated project and to identify the risks. And UX should be the champion of this process.

I am going to describe a process which I have used for years and which, well, it simply works. It is not a static workflow, it changes to meet the needs of the project and, this is the crucial aspect, most methodologies are all wonderful on paper, but they need to be able to adapt to the project.

My preferred workflow does require several items from the client and these are time boxed decisions, which are either set in a stone calendar, or will incur a penalty (late delivery being the usual one) It needs responsible stakeholders who are not going to be overridden by a director who really holds the purse strings. It requires timely access to run UX research, requirements interviews and access to assets and data. And it requires some flexibility which is hopefully born through trust and honest communication. With these items in place we can hopefully deliver a happy solution.

Most other problems (resourcing, resourcing, resourcing) can be handled, but what we do need throughout a project is a collaborative partner in the form of the client.

My process starts with a generic RfI and RfP. This should be written by knowledgeable technical, UX, marketing and strategy people. It should outline three concepts with an MVP (minimal viable product, a.k.a ick), a middle of the road solution with some whistles and an occasional bell, and a HUGE all singing and dancing solution which costs about the same as a small diamond mine. We want them to go for the middle option, maybe with an occasional bell from the top option but never, ever, the MVP – this spells disaster, it means the client is tight on the purse strings and we will not end up with joy and happiness.

Any RfI or RfP estimates should be real, we shouldn’t be knocking off 30% in order to catch the client, real money for real work. If you really, really need the work, then take it off the profit margin but don’t take it from the poor designers and developers, all you will create is chaos and unhappiness.

After winning, the first step is usually a requirements workshop. For a medium sized project this is usually a 2-5 day affair with all relevant stakeholders and knowledge bearers. We need to fully understand the business in order to present a solution. The workshop is driven by a UX architect, i.e. someone who will be able to bring pure UX, technical understanding and business analysis to the the party. We need to have the senior designer there in order for them to fully get what the client needs and wants. We may need other specific technical bods if the UX allocated consultant is not capable of translating wishes into effort and time/cost or of validating technical options.

The UX architect must understand that this is not his/her pet project, instead it is a collaborative effort and, whilst it is OK to have a broad outline in the agenda for areas to be covered, they should be spending most of their time listening and not dictating.

Saying that, I usually schedule a full day before the workshop in order to create a pseudo project within scope and to have enough material and understanding of all areas of the project and the clients’ business to be able to challenge and start a discussion. You don’t want to ad-lib this. There is nothing worse than just standing there in silence when the clients are not being the best communicators.

Keep the workshop grounded, it is important to not lose all the effort spent on your proposal to be lost. If the client suddenly mentions having a plugin on the site to read minds, gently steer them back to the original budget or, as a minimum, suggest a new number for them to consider when aspects are introduced that exceed the initial scope. Scope creep is:

  • A. good, because it implies an excitement from the client
  • B. bad because it can very easily become unmanageable and unless controlled create disappointment or disillusionment.

What areas are covered in the workshop:

  • General overview just to set the scene for the agency
  • Current situation – the good, bad, ugly
  • business analysis overview
  • competitor analysis – what are they doing well, badly and areas we can improve on
  • Persona identification – who is going to be using this site (backed by analytics)
  • Persona focus, who do we need?
  • Persona ideal journeys/stories – high level – including the business analysis of said stories
  • Journeys/stories summarised and detailed step by step [logic diagram]
  • Entity identification, history and dissection
  • Flow diagrams of the journeys
  • Wire frames, annotated

At the end of each day it is important for the UX architect to collate the information and be prepared to lead the next section, again always with the thought that they need to gather rather than set the requirements. It’s collaborative!

The output of the workshop is a series of stories, I tend to use postcards, and hopefully key entities and some wire-frames. At this point there is a break of 1-2 days where the internal reaction to the workshop occurs. The home team will be present, so UX, along with the technical lead and maybe extra developers, test/QA, design lead, infrastructure and PM. The workshop output now gets analysed by the team. Each story is broken down into actual digital real estate and processes and is budgeted. Epics are created and within those stories. Stories can be classified further into areas of nice to have, or required. ALL this information is collated onto the cards with a budget of 1,2 and 4 to indicate complexity.

The result WILL be over budget, probably significantly, and the client will need to have this demonstrated to them. For this I really like the pocket money game. Get a load of coins which represents the agreed budget. Next lay out on a large table all of the story cards and allow the client to “spend” his budget. This really shows off the internal prioritisation of items and also makes them really do the MoSCoW analysis themselves. Quite often we will make undertakings that, depending on how each sprint goes, we may have the option to include some of the lower scored elements, but if they want to exceed the budget, they can and it will cost and may involve extra sprints (this is the agile perspective). What we do need here is agreement from the design and technical team as to what is feasible within each sprint including management and test overheads.

After the game we have prioritised stories – each with a technical summary and detailed non-functional requirements (test criteria). We can now look at resources and start planning the project into dates and sprints. With UX research (if you are lucky), prototypes (design + tech), functional planning and documentation, main design and technical sprints in a staggered array, test/QA, infrastructure and launch. There are more steps in each area, but you should get the gist.

For those argumentative types out there, they might be asking why this is different from any standard workflow. The main differences are that the design is UX driven i.e. driven for the business by the needs of the customer. The development team gets involved early to assist with realistic expectations of time versus requirements, the design team is coming from a much fuller empathy driven perspective. The client gains a full understanding early on about effort, risk and consequences as well as providing them the option to go back and extend the budget. And yes, we can adapt, we can change scope – but if this does happen, the client needs to be made aware of the impact of that change for the whole team and the project documentation.

Of course there are going to be disasters, no digital project I have ever seen does not have at least one. But if you have a project planned like this, you stand a pretty good chance of success as well as having and keeping a client.

To conclude, is this agile? Not in the strictest sense, but why do we need that anyway? We have ended up with a manageable project with an aware client, UX driven and sprint enabled for design, development and test – to my mind that’s good enough.