- Advertisement -
- Advertisement -
- Advertisement -

Find a job

Subscribe for free

All things Pharma

A guide to implementing Agile in pharma

Following his article on Agile and its role in addressing pharma’s productivity problems, Neil Osmond shares his guide to implementing Agile in pharma.

If you’ve read A New Mindset: Implementing Agile in Pharma and want to know more about how to implement Agile, this is the guide to the key terms and approaches for you.

If pharmaceutical companies adopt the principles, and some of the methodologies that have been built on the Agile principles, it can have a big influence on:

  • Developing real world solutions that solve true customer problems
  • Minimising wasteful work and focusing on what is really going to make a difference
  • Getting the best out of teams and helping them to feel like they are contributing value every day.

Defining productivity

If we define productivity as:

then Agile can make a positive difference to the top and the bottom of this equation. It helps to increase the Output by embracing change, involving customers and launching solutions earlier. It also helps to decrease Input by reducing wasteful activity, finding and fixing issues earlier and doing the most valuable things first.

When to use Agile in pharma

However, it’s important to consider when to use Agile in pharma and when to use waterfall.

If your project is something you have done many times, there is a clear process, the outcome is specifically defined and there is little ‘value added’ thinking on the journey, then use the waterfall method which flows in a single direction in logical steps.

However, if your project has unknowns, requires significant thinking and the exact inputs, outputs, outcomes and process may be understood at a high level but not at a detailed level, then use Agile.

And if you’re not sure or the project isn’t black and white, then consider these simple questions and scoring system to help you decide.

If this leads to the Agile way of working, you then need to consider which Agile methods, meetings and tools to employ.


The core team

Some key roles (not necessarily full time) should be considered for every project.

Each project needs a Leader to hold the vision for the project and make the decisions. The leader needs to be supported by a Project Manager to make sure everyone is doing their job and the project is being run efficiently. Creating the detail of a solution though needs one, or more, Knowledge Experts that typically have detailed understanding of products, systems and processes. The key role that is most forgotten though is the User Representative(s) who take on the voice of the user. You need this person on the core team to ask the difficult questions such as ‘Has anyone actually spoken about this to a customer?’. Depending on the project, these roles may not be full time, but they are all important roles.


Sprints are a set amount of time to achieve specific tasks in the project. They allow everyone to focus on the agreed amount of work in the agreed amount of time. Sprints should be long enough to see a significant progression that you can tangibly measure, but short enough to concentrate minds on achieving a goal.

Sprints are rarely less than a week and never longer than four weeks. If a project is no more than a month, then we’d suggest one-week sprints. Between one and three months, with lots of resources then one-week sprints, if resources are less concentrated then probably two-week sprints. If the project is greater than three months then you may consider four-week sprints, but this is a very long time and lots can change, meaning what you planned may become increasingly irrelevant.


One of my team once said: “Meetings are the place where work goes to die”. Whilst this is an extreme view, I am sure many of us have been in meetings which feel like that. However, if you have the right combination of meetings, with the right people involved, that are tightly run, meetings can increase productivity.

Consider each type of meeting and which is most appropriate at that time.

Sprint Planning

This is one of the two key meetings and can be 30 minutes or less if planning is completed beforehand. At the meeting, the tasks at the top of the backlog (or ‘to do’ list) should be ratified, estimated, agreed and assigned with the whole team. It should be chaired by the Project Manager with the Leader in attendance to make key decisions. There should also be a goal set for the sprint so that the team knows when it is done, what success will look like and whether they can celebrate, or not, at the end of the sprint.

Sprint Review

This should be chaired by the Project Manager and often it can be 30 minutes or less. It is the other key meeting for every core team member. In this meeting, each core team member gives an update, showing their work wherever possible. These should be quick with any detail comments, or questions, saved for afterwards. Each of the sprint tasks should be considered and whether they’ve been completed successfully. If they haven’t, they are moved back to the backlog or to do list.

Remember 90% done is NOT done.

If you meet, or exceed, your goal – celebrate in some way. And if you don’t, remember, you succeed as a team and fail as a team. Just because it had someone’s name on it doesn’t mean someone else couldn’t have helped out.

Sprint retrospective

One of the principles of Agile is ‘Regularly, the team reflects on how to become more effective, and adjusts accordingly’. This is particularly useful at the end of a sprint to make adjustments for the next sprint. To do this, consider undertaking a sprint retrospective and combining it with a review meeting chaired by the Project Manager. Keep it simple with everyone answering two questions:

  1. What went well and we would repeat?
  2. What would we do differently in the future?

Consider the answers to these questions and write them where everyone can see them in order to change behaviours and practices for the better. Also, review previous retrospectives regularly to see if the team has followed through.


Standups or scrum meetings are short, sharp touchpoint meetings within a sprint. As a rule of thumb, allow 90 seconds per person per meeting to answer the following:

  • What have I done since the last touchpoint?
  • What am I planning to do before the next touchpoint?
  • What is getting in my way?

Further conversations should be held outside of the meeting (or after, if the right people choose to stay on after and let the others disappear).

Other things to consider

Kanban boards

You need somewhere to see and track progress. In some ways, it doesn’t matter what it is but the best solution we have found is Kanban boards. It could be a physical board with post-it notes or a digital board.

Gantt Charts

True Agile zealots would probably scream at the mention of a Gantt chart but, if they help you to engage with stakeholders or have a long-term view on the direction of the project then feel free. However, remember that using a Gantt chart doesn’t mean future possibilities are guaranteed certainties and that following the chart dogmatically assures a positive outcome.

Face-to-face or remote meetings

If your core team is co-located, meet face-to-face in one location. However, if a core team member is not office-based, or you have engaged external help, then consider which meetings should be remote and which co-located. Remote meetings can be face-to-face by using video.

Chat solutions

Using chat solutions can speed up communication, reduce email traffic and help to integrate a team (especially when not co-located).


Before you put a task into a sprint, you should:

  1. Estimate how long it is likely to take
  2. Understand who can do it and whether they have capacity in the sprint
  3. Make sure it isn’t blocked by anything.

Definition of done

This is really useful for tasks where clarity is important. When creating a task, specify the ‘definition of done’. It can ensure time isn’t wasted when a task is assumed to be one thing, but the Leader believes it to be something slightly different. It also helps everyone to recognise then sprints, tasks and the project is done.

By following these key elements of Agile, you can begin to work in an Agile way and address the productivity problems faced by the pharmaceutical industry.


Neil Osmond is a technologist and founder of digital agency earthware. He has 20 years’ experience in healthcare and a passion for solving problems for patients and healthcare professionals.

- Advertisement -
Neil Osmond
Neil Osmondhttps://earthware.co.uk/
Neil Osmond is a Technologist and Founder of earthware, a digital healthcare agency.


- Advertisement -



Sign up to receive our digital newsletter, for all the essential headlines, Jobs of the Week and thought-provoking features.

Claim my free subscription