In part 1 we looked at when you would use Agile, the team you need and sprints. Now we will be talking about the meetings, tools and other considerations involved in Agile development for the pharmaceutical industry.
Meetings
As one of my team once flippantly 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 where we believe it is taking too long, the wrong people are in the room, it lacks focus and where the meeting lasts the time it is booked for rather than taking as long as is actually needed.
On the surface, many methodologies of Agile seem to have more meetings, not less, and this was a concern to me as a Leader when we decided to move in this direction some years ago. However, our experience is that, if you have the right combination of meetings, with only the right people involved and they are tightly run then these meetings can increase productivity.
If we use the Scrum methodology as a basis for the types of meetings you may have, here’s how we consider which ones we do (in order of importance):
Sprint Planning
This is one of two key meetings that the core team should attend. Often this meeting can be half an hour or less (if some planning is done beforehand). In this meeting, the tasks at the top of the backlog (or “to do” list) should be ratified, estimated, agreed and assigned with the whole (core) team as well as your design/development team (as appropriate to the work being planned). It should be chaired by the Project Manager and the Leader should be in attendance to make key decisions. There should also be a goal set for the Sprint so that the team knows what success will look like and whether they can celebrate, or not, at the end of the Sprint.
Sprint Review
This is the second of the key meetings the core team should attend. It should be chaired by the Project Manager and often this meeting can also be half an hour or less. 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 tasks in the Sprint should be considered with the Leader signing them off if they’ve been completed successfully, or not if they’re incomplete or have bugs/issues (in which case the task should be moved back to the task ‘backlog’ (or ‘to do’ list)). Remember, 90% done is NOT done – it must go back to the backlog list and may be finished in a future Sprint (with a reduced estimate). 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 picked it up or helped in some way.
Sprint Retrospective
One of the principles of Agile is “Regularly, the team reflects on how to become more effective, and adjusts accordingly.“ We thoroughly recommend a Sprint Retrospective and we often combine it with the Sprint Review. This should be chaired by the Project Manager and should not take very long: we tend to keep it as simple as everyone answering two questions:
- “What went well, and therefore we would repeat?”
- “What would we do differently in the future?”
There are lots of methodologies for doing retrospectives, and many tools (e.g. Retrium), but for most projects, considering the answers to these questions and writing these down in a place where everyone can see them, is often enough to change behaviours and practices for the better. We would recommend you review previous Sprint Retrospectives regularly to see if the team has followed through on what they suggested.
Stand-ups
Often also known as Scrum Meetings, these are short, sharp touchpoint meetings held every day (ideally) of a Sprint. They shouldn’t last more than 15 minutes: As a rule of thumb, we would allow 90 seconds per person per meeting and we would recommend each person answers the following:
• What have I done since the last Stand-up? • What I am planning to do before the next Stand-up? • What is getting in my way?
Please resist the temptation to talk about the weather, your weekend plans or to even expand on what people have said (for example how to solve a problem that is raised during the Stand-up). All of these are great but should be done outside of the Stand-up meeting (often if the right people are around then they may choose to stay on immediately after the Stand-up and let the others leave). We regularly have Stand-ups with 8-10 people on them that take no more than ten minutes – it can be done!
Other things to consider
Kanban boards
You need somewhere where you can all see and track progress. In some ways, it doesn’t matter what it is but the best solution we have found is using a Kanban board. This can be a physical board in your office with post-it notes or a digital board (we have used Microsoft Planner, Trello, Teamwork, and Jira but there are many others available too). We would suggest that a physical, visual board is best but as soon as one of your core team is not office based then it becomes impractical and so the vast majority of our projects use digital boards.
Gantt charts
True Agile zealots would probably scream at the mention of a Gantt chart. However, Agile is not anarchy and if this helps you engage with stakeholders or have a long-term view on the direction of the project then feel free. I would just caution that as soon as something gets written on a Gantt chart, by some magic that I don’t yet possess, stakeholders believe the future possibilities become guaranteed certainties and that by following the chart dogmatically a positive outcome is assured. Please don’t fall into that trap.
Face to face or remote meetings
This is often a consideration when planning a project and our recommendation is that if your core team is co-located then meet face to face in one location – all studies I am aware of suggest that the most effective communication is done in this way. However, as soon as a core team member is not office based, or you have engaged external help, such as agencies, then you should consider which meetings should be done remotely and which co-located.
However, remote meetings do not mean they are not face to face! We thoroughly recommend having video enabled on every possible interaction. We would also recommend that if some of you are co-located, and some remote, resist the temptation for the co-located people to go into a room and the others to dial in. It may give a better experience for the people in a room, but it will give a worse experience for those that are remote. If you are OK with some of your team feeling like second class citizens, then go ahead. However, we prefer to adopt a position that if one of us is remote we all join on our PCs/mobiles etc.
Lastly, this doesn’t have to be expensive. There are many cheap, or free, solutions including appear.in, Zoom, Google Hangouts, Skype, Skype for Business, Slack and Microsoft Teams. We have used all of these depending on preferences and our client’s experiences or technical architecture.
Chat solutions
We have found, over time, that using chat solutions can speed up communication, reduce email traffic and help to integrate a team (especially when they are not co-located). Key things we communicate through chat channels are:
- Where we all are today
- Questions I need an answer to within the next 24 hours
- Interesting things we have found
- Discussion threads
The two chat solutions we have used extensively are Slack and Microsoft Teams but the technology is far less important than finding a way to use them that works for your specific team and your specific project.
Estimating
Before you add a task to a Sprint, you should have done three things:
- Estimate how long it is likely to take
- Understand who can do it and whether they have capacity in the sprint
- Make sure it isn’t blocked by anything
Estimation is often overlooked but not doing it, or not doing it accurately, is a common reason Sprints fail. Over time we have used methods to estimate tasks including:
- Time (hours or days)
- Story Points
- T-shirt sizes (e.g. XS, S, M, L, XL,)
And we often use a method called Planning Poker to help achieve a more accurate estimate (with input from all involved in the task) and ensure that we are not missing a short cut to complete the task in less time.
Definition of Done / Acceptance Criteria
This is really useful, and we recommend using this on tasks where clarity is important. To give you an example, a client recently demoed a Business Information dashboard solution to me, and it took over 20 seconds to load (from clicking on the icon to the first screen appearing). This was on an office PC with a wired network connection. I can only imagine what the experience would be for a Manager in a remote part of the UK using a laptop tethered to 3G or 4G! That would be unacceptable to me, but I suspect no-one specified to the development team what an acceptable performance was so I suspect they could claim the task was completed successfully. When we create a task, we often specify what the “Definition of Done” is. For example, a website home page may be considered done when:
- The designer has checked it to make sure it matches the design
- It loads within 2 seconds on a 10 mbps connection on a PC
- It works on the specific devices and screen sizes we support
This can really help to make sure that time isn’t wasted when a task is assumed to be one thing when the Leader believes it to be something slightly different.
In part 3 of this series we will be looking at a case study and other considerations for using Agile.
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.
