Illustrated books

An introduction to Agile

Agile has been around in the digital sphere for years. Almost every agency these days will be promoting Agile project delivery in one sense or another. But Agile can be baffling. There’s so many rules, so much jargon, it can sometimes feel like a secret club that you’ll never get into.

To help you cut through the noise on Agile, here’s my no-nonsense introduction to digital Agile project delivery.


Agile is a framework for how to deliver projects. It’s not a methodology. This means it’s a structure which provides a process for delivering projects, but leaves tools and specific practices open for the user to choose.


There are a few common roles you hear when people talk about ‘working Agile’. A lot of them start with the word Scrum – Scrum is a methodology within the Agile framework. Don’t worry too much about that now. Let’s focus on the basics first.

Here are a handful of the most common roles people will refer to when talking about Agile project delivery.

Scrum master
Essentially a project manager. The Scrum master is responsible for ensuring the project is delivered.

Scrum team
The project delivery team. Normally, a multi-disciplinary team that work together to deliver work.

Product Owner
The client. One client who has the responsibility and authority to make decisions about the project scope, budget and length.


There is a key ideological difference you need to be aware of and adopt when delivering an Agile project. While other frameworks are about the project manager controlling the project, Agile is about a project manager (or Scrum master) facilitating a project.

This means it’s all about making sure people have the right information, tools, touch points and direction to build a successfully functioning piece of digital.


Agile ceremonies are really just meetings that need to happen to work in an Agile process. These typically include:

Daily stand up
A short meeting held once a day with all the project team and often the Product Owner (client).

The same script is followed each day. Each person says what they did yesterday, what they’re working on today and raises any issues or blockers.

It’s designed to allow the whole team transparency on what others are doing, as well as highlight when someone is spending more time than anticipated on something.

Sprint prioritisation meeting
Held on the first day of each sprint, this meeting is attended by the team and Product Owner and in it, work is chosen from the backlog (a list of features, functionality, ideas, technical debt, bugs and tasks) to be completed within the sprint.

Tasks are sized (estimated) by the team to ensure they are committing to the right amount of work.

The period of time in which the team are working on a specific set of tasks. Typical sprints are 2 weeks in duration but 1 week or 4 week sprints are not altogether uncommon.

Show and tell
At the end of each sprint, the team presents the completed work to the Product Owner in a meeting known as a show and tell, wip (work in progress) review, or sprint review.

At the end of each sprint all team members are invited (and encouraged!) to give feedback about how the sprint went.

The idea is to learn from mistakes and successes and feed them into the next sprint to make it more efficient, collaborative, and fun.


There are twelve key Agile principles, but they are really for the hard core Agile lovers who are working on software development. The main things to know and adopt when working Agile are

  1. Prioritise face to face communication and collaboration. This goes for your team and clients.
  2. Sprints are fixed. Once a sprint has started and the work has been agreed in the sprint prioritisation meeting, it cannot be changed or altered.
  3. Be flexible and willing to change direction at the end of each sprint to respond to changing requirements.
  4. Everyone is responsible and all team members hold each other accountable for delivering the project.
  5. Work should be broken down into small increments to make it easy to define, size, assign and test.
  6. Always work with delivery in mind.The idea is to develop working digital products quickly and continually iterate them.


Agile has gained popularity in recent years but that doesn’t mean it’s a silver bullet to project delivery.

Agile works well if you have a dedicated team for the project, an innovative product or evolving scope, a client who is happy not getting everything they want in the first release, enough internal rigour to ensure the ceremonies are adhered to, and a team located in one office.


Do you feel confident running an Agile project? I’d love to hear your feedback in the comments below.

Agile Inception techniques

Agile project inception techniques

You often hear agencies talk about running ‘agile’ projects which usually ends up being hybrid wagile or planning + iterative development. Lots of agile books dive right in to delivering the project, mid-code and everyone on board. So one thing that interests me a lot is how to run a truly agile project inception. I was lucky enough to attend DeliverConf’s 2017 workshop day in which Delivery Director at Valtech, Kevin Murray, discussed this very topic.

As it turns out, truly agile project inception is actually a lot more similar to waterfall in its aims than you may think. You still need to understand your client’s business, their users, stakeholders and objectives. You still need to find a good digital solution which is feasible and realistic. You still need to gain buy-in, confidence and build the foundations for the project delivery. What was in stark contrast was the amount of collaborative exercises that are done with the team and client as well as the role of the project manager. I’ll explore a few more of these exercises in depth below, but here is a photo of all of the agile inception techniques that Kevin may draw on when starting a project.

Agile Inception techniques

One really interesting thing Kevin mentioned was that running an inception phase with this approach meant it was okay for a client not to have all the answers. Typically in waterfall we ask a client to drive the development of a list of requirements (especially for cost reasons if there’s a tight budget). This puts the assumption and risk onto the client that they must have all the answers immediately and up-front. I’ve seen first hand that this can fill clients with ‘project FOMO’ or make them overly and unnecessarily lofty and abstract in their requests.

So, what agile inception techniques are available to help clients (and teams) who don’t need to know everything right here, right now?

As you guessed from the name sliders are a set of criteria which can be assigned a value (e.g. 1 to 10). Clients can slide the values higher or lower to demonstrate which criteria are fixed, and which are flexible. For example, your client may say that accessibility is absolutely fixed, but security is flexible. Such a site may exist for a marketing site for a charity which supports the deaf-blind. It has high accessibility needs, but as a marketing site doesn’t need Fort Knox security.

An add on from me, would be to set the values between 1 and 10, with 1 the most flexible and 10 the least. Then, times the number of criteria by five (e.g. 10 criteria x5 = 50). The total here gives you a total amount of points which can be assigned amongst all criteria in order to determine the relative flexibility or rigidness.

If you find your stakeholders really struggling with the number of points they can assign it’s a good indication that there are too many fixed elements and that either something needs to change at the stakeholders end, or you should have a conversation about whether agile is the right delivery framework for this project, at this time.

If your clients can assign all of the points and come to relative consensus on them, you have a great understanding of the project’s priorities in order for it to be successful.


Assumption mapping
Assumption mapping allows everyone to have a say about things which either seem really obvious to them, or feel a bit risky because they don’t know the answer. It’s a great technique for when there is a shared and understood idea about what you’d like to do for the delivery phase.

Take a big sheet of paper and draw an intersecting x and y axis. Name one axis Certainty, and one Immediacy. Ask all your stakeholders and team to begin jotting down their assumptions onto post-its. It’s okay if you have loads – that’s the idea! Better to ask the question now than be thwarted by an assumption later down the line.

Once your stakeholders and team have a good list of assumptions ask them to start placing them into the relevant quadrant – certain and immediate, uncertain and immediate, certain but not immediate, uncertain but not immediate.

  • Certain = how sure are we that x is feasible?
  • Immediacy = how urgent is this feature to include in the MVP?

Once you have a finished and well debated map, you can pass it over to your team for technical, user, and business analysis and investigation. The aim is to move everything out of the immediate and uncertain quadrant either by establishing its feasibility or by de-prioritising its immediacy. This will help you generate a first draft of features and stories before committing them to a more formal backlog.

Assumption map

Vision statement
A good tool to sense check thinking and collective understanding of the proposal is the vision statement. Done well, it guides the project, working as a checkpoint for feature proposals, objectives, and product or service aspiration.

Best used once you have completed some initial brainstorming and research, it works simply by following the formula and filling in the blanks:

  1. THE (name of product/service)
  2. FOR (users of product/service)
  3. WHO WANT (key features of the product/service)
  4. THIS SERVICE(S) WILL (sub key features)
  5. UNLIKE (existing/competing product/service)
  6. THIS SERVICE WILL (key differentiation/advantages of product/service)

The idea is to get to a vision statement that everyone agrees sums up the aspiration.

Vision statement

Apart from the above inception techniques one of the things I took from Kevin’s workshop was the level of involvement the UX researchers, business analysts and client stakeholders have in the inception period. As well as the need to have good quality users available at relatively short notice to ‘real-world sense check’ ideas. Additionally, the role of the project manager in this stage was far less about planning and far more about facilitating workshops, conversations and exploration.

You can view Kevin’s full presentation on slideshare.

I’d love to hear about any agile inception techniques that you have used and have found to be really successful.