We've spoken a lot about Agile development and how it can benefit digital projects. In this blog series we will delve deeper into using Agile in the pharmaceutical industry.
Does Agile have a place in pharmaceuticals?
The short answer is, we believe, yes; but only for some projects.
Caveats first: Most of our experience is in global marketing functions and local pharmaceutical affiliates as we do not tend to work in clinical, R&D, manufacturing or distribution very much. However, in our experience, if pharmaceutical companies adopted the Agile principles, and some of the methodologies that support it, it can have a big influence on:
- Developing real world solutions that solve true customer problems
- Minimising wasteful work enabling greater focus 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
But why? Here’s the science bit. If we define productivity as,
then we believe Agile can make a positive difference to both the top and the bottom of this equation.
It helps increase the valuable Output by embracing change, involving customers and launching solutions earlier.
It helps to decrease the Input by reducing wasteful activity, finding and fixing issues earlier and doing the most valuable things first.
But how much can it help? As an example, if you can increase the value of the output by 20% and decrease the cost of the input by 20% then the productivity increases by 50%!
In our experience these figures are very achievable and are often much better than this. We recently trained, and then coached, a cross functional brand team in their first project, a digital communication to customers. Historically, such projects typically took 6 to 12 months from conception to completion. Despite their lack of familiarity with Agile concepts at the outset, the team completed this project in 3 months. They would probably say a big reason for this quicker delivery time was because they were able to identify and remove everything that wasn’t focussed on delivering the solution and because they were able to engage everyone on the journey (including their agencies, representatives and customers) which reduced bottlenecks and delays. Their reflections were that now that they had the hang of Agile, they could probably do the next, similar, project in half the time.
Remember, at the beginning I said, “yes; but only for some projects”. Perhaps the question I get most often asked is, “When should we use Agile and when should we not use it (or when should we be using waterfall instead)?” I have answered this in lots of different ways, but at its simplest: If your project is something you have done many times, there is a clear process, the outcome is tightly defined and there is very little ‘value added’ thinking on the journey, then use waterfall – it works!
However, if your project has unknown elements, is going to require significant thinking on the journey and where the exact inputs, outputs, outcomes and process maybe be understood at a high level but not at a detailed level, then use Agile principles and methodologies.
So, what happens when the project isn’t this black and white? Well, we have developed several simple questions and a scoring system that can help you decide how ‘Agile’ you think your project should be run.
We have also created an example of how we make decisions about what kinds of Agile methods, meetings and tools we employ in the real world.
Once you have this indicative score, the next question is “So what?” In our view, you should consider, what methods and artefacts you should use on a project by project basis. We would argue that if you unwaveringly commit to all the artefacts of a single methodology (e.g. Scrum) without flexibility then that dogmatic approach cannot, by definition, be truly ‘Agile’.
These are the artefacts, and approaches, that we consider when setting up a project:
People
The core team
We believe, there are some key roles (not necessarily full time) that should be considered for every project. These are:
Leader
We recommend you have a Leader (also known as a Product Owner) on every project. In the end, someone must hold the vision for the project and make the decisions.
Project Manager
We recommend you have a Project Manager (also known as a Scrum Master) on every project. It is their job to make sure everyone is fulfilling their roles, to clear impediments and ensure the project is running as efficiently as possible.
Knowledge Expert
You may need several Knowledge Experts through the life of the project depending on the complexities and how much you create in house or outsource. Knowledge Experts typically have a detailed understanding of systems and processes (e.g. IT), understand the products and services in detail (e.g. medical), or perform crucial functions (e.g. compliance or legal). The Knowledge Expert may be transient but while they are working on the project, they should be on the core team.
User Representative
The User Representative role is often overlooked on projects, but we believe it is crucial. On the core team you should always have someone to take on the voice of the user, the beneficiary, the person whose problem you are trying to solve. They should not be someone whose neck is on the block if the project isn’t delivered on time or on budget, but should be there to ask the difficult questions like, “Has anyone actually spoken about this to a customer?” and to make the uncomfortable, yet vital comments such as, “I understand it because I have been in this meeting, but I genuinely think that customers will be confused and therefore not bother.” This role saves so much time and money in the long run, even if their comments are frustrating in the short term. Ideally you would have a customer in your core team but if that’s not possible then aim for the closest thing: maybe an employee who is not on your team but who has some personal experience in the project area, or maybe someone from a patient group, or a retired GP etc.
I appreciate that for small projects, with short timescales and small budgets, having four people may be impractical. However, in this scenario, team members should actively try and make sure these roles are covered by thinking about which mode they are in (a little like Edward de Bono suggests in his bestselling book “Six Thinking Hats”). Maybe one day, they are in Leader mode, considering options, engaging stakeholders, making decisions and the next day they are in Project Manager mode moving tasks forward, planning, documenting, checking budgets and doing admin.
Broader team(s)
We will always consider the broader team before kicking off a project. Our thinking is in line with a RACI analysis – those Responsible and Accountable should be on the core team, but those who should be Consulted and Informed may be on one, or more, broader teams. An example of the broader teams might include:
Design team
The people involved in developing and checking designs and design decisions.
Governance team
The people who understand the non-functional requirements and considerations (such as IT, legal, medical, compliance).
Training team
The people who may be responsible for a successful roll out (such as product champions, training, sales management).
Sprints
Sprints are not magic. They merely allow everyone to focus on an agreed amount of work in an agreed amount of time. They should be long enough to see a significant progression that you can tangibly measure, but short enough to concentrate minds on achieving a goal. Here’s how we think about this. We rarely suggest sprints of less than a week and never longer than four weeks. If a project is no more than a month then we would suggest one-week sprints. Between one and three months we would suggest that if lots of resources were being deployed then one-week sprints, if the 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, to be honest, we have never done this as four weeks is a very long time and things can change a lot, meaning what you planned may become increasingly irrelevant.
There is no set formulae for this though and we have done shorter sprints. If you have an intense week-long project you may decide to have one-day sprints: we even did a two-day hackathon once where we were doing two-hour sprints which worked really well.
In part 2 of this series we will be looking at the meetings, tools and other considerations involved in Agile development for Pharma.
If you are interested in how an agile mindset might help you be more productive as a team, visit earthware.co.uk/agile or drop us a line.
