2agile4academia?

I formally led a software development team for the first time as part of the Scottish Covid Response Consortium’s (SCRC) contribution to the Royal Society’s Rapid Assistance in Modelling the Pandemic (RAMP) initiative. The software is Simple Network Sim and was created by Jess Enright, the overall and academic lead for the project and a lecturer at the University of Glasgow. I felt a bit out of my depth to start off with, but the team were fantastic (and mostly way better at Python than me) - I hope my leadership helped them to do their best work. I can’t think of another time I’ve learned so much in three months.

This post is about management and leadership on the project.

Our software

Simple Network Sim models a covid-19 pandemic by breaking a population down into nodes (representing specific geographic areas) in a network. Each node has numbers of people in various states (e.g. exposed, infected, recovered, dead) and the model is parameterised with rates of transition between these states. This is modified by levels of mixing between people of different age groups. People also move between the geographic nodes so changes in movement patterns can be simulated. This means it’s possible to simulate things like:

• Effects of changes in understanding of disease progression (e.g. a new intervention that reduces the rate of change between numbers exposed and infected).
• Effects of changes in age mixing behaviour (e.g. grandparents providing childcare).
• Effects of changes to commuting patterns (e.g. reopening offices in one area and not another).

Our software was one of a number of projects under the umbrella of SCRC. The idea being that you can run the same simulation scenario, with the same data on say six different models and cross-validate the results. Ambitious and potentially very powerful.

Making it happen

I wanted to think about the project management / leadership role. When this first came up as something for me to maybe do, I remember saying to our team leader “This is not a well scoped project.”. And it wasn’t. How could it be with the coronavirus situation changing daily? It wasn’t clear what my role would be, or really what we were aiming for. I was OK with this, but it meant that we weren’t making any Gantt charts! The team grew week by week with full time and spare time contributors. We were in the realms of what we kind of call “agile” without really knowing what that means. I’ll explain what I actually did, then explain how it fits with stuff I’ve found online about project management (and my two years of study for dated management qualifications).

• A vision of good software Jess is a computer scientist and an epidemiologist and has the overall vision for what the software should be capable of. My role, as I saw it, was to push us towards doing stuff that would make our software well-engineered e.g. documentation, testing, continuous integration, balanced with adding functionality. I was lucky in that this was a vision shared by a team who valued and delivered good software engineering.

• Chairing weekly stand-up meetings Every Monday at 9:30 everyone involved with development on Simple Network Sim got together on a video call and we went round, one at a time, and talked about what we’d done the previous week, what we planned for the next week and whether there were things outside our control that were holding us up. We then reviewed the project board…

• Project board (Kanban) Our work was broken down into GitHub “issues” which were usually assigned to individuals. These were arranged on the project board into “ToDo”, “In Progress” or “Done”. In our weekly meetings (and as needed) we would add to these, assign, move them into the most appropriate column, etc. This approach was (I think wisely) mandated by SCRC with issues shared across the consortium.

An example project board

• Tracking progress The project board is great - it lists everything that needs to be done so no-one has to store this in their head. You can even tag things as being “high priority”. What it doesn’t do is track task dependencies i.e. this needs done before that - that was in my head. Towards the end of the project we brought in a milestone (we only had one in the whole project) to focus us on finishing key tasks while we still had resources.

• Automation, review and documentation We required that all code be reviewed prior to being merged into our master branch. I was much more likely to be reviewing code than writing it! Early on we set up continuous integration such that tests were run and coverage reported prior to any merges. Along with this I wrote (and cajoled others into writing) project documentation - contributing guidelines, code style, data dictionary, readme… I think having these was really helpful as new people joined the project.

• Continuous communication SCRC provided Zulip instant messaging which we used extensively (I wouldn’t be surprised if I wrote 1000+ messages), both within our team and for…

• Liaison I found myself being a point of contact between team members, other teams and consortium leadership. I had to be able to explain the Simple Network Sim team’s position to the others and vice versa. I had to explain our decisions.

• Problem solving / technical advice More or less technical problems (stuff like how do we implement something - there are often several ways) involving multiple stakeholders popped up all the time, often I could help with these and make decisions allowing us to proceed.

• Reminding people to do stuff Polite reminders (e.g. to review a pull request).

• Encouragement I don’t know how motivating this was, but I tried to acknowledge the work people were doing in comments on pull requests, instant messages and in meetings. And I tried to keep the team positive and constructive in their interactions - this was made extremely easy by the team members!

Reflection

Without buy in from the rest of the team, much of this stuff I was doing wouldn’t have been very effective! (No point in sending 100s of instant messages, if everyone insists on using email.) The team was comfortable, I think, with the way we worked.

I just had a look at agilemanifesto.org. I think we were inspired by this indirectly, but I don’t agree with it in it’s entirety. I’ve also had a look at Scrum which falls under the agile umbrella, but I guess is more formalised. Our meetings and interactions, particularly with stakeholders fit into the general idea of Scrum, where requirements can change and working software is delivered regularly. In fact, our testing, CI and review process meant we always had “working” code. We didn’t do anything called a “sprint” and our meeting duration and frequency was of our own devising. I think we captured the agile ethos - we’d have been lost without it. A traditional waterfall approach (which when I studied project management formally was the only approach taught) would have meant constantly revisiting plans and redrawing Gantt charts, or giving up altogether.

Personally, I was worried about my lack of experience at the start of the project - however it turns out that years of interdisciplinary research working with PIs, students, technicians and postdocs in chemistry, physics, engineering, medicine and biology yielded some useful transferrable skills. I would like to know more about how to do “agile” and “Scrum” properly - maybe I’ve missed something really important? Would a proper “Scrum-Master” think this blog post laughable? But I’m minded by my experience of studying management (albeit 15 years ago) - management models are rarely based on quantitative evidence in the way that scientific models are. There’s no proof they’re going to work in a particular situation.

Lasting changes?

I’ve come out of this convinced of the value of the agile approach. I think academia uses it a lot without realising it and can be stifled by demands for plans in the form of Gantt charts and the like, when requirements vary wildly as new discoveries are made.

A lot of the technical aspects of this (e.g. continuous integration) are project- and language-specific, and much we do routinely as standard, however I’m going to try and routinely make sure there is instant messaging and a schedule of meetings for my future projects.

A challenge for the future is how to reconcile the adaptability of these methods, which are great at responding to quick changes in needs, with the requirement to hit specific milestones on particular deadlines in an academic environment where a project’s resources are capped years in advance.

This project was pretty different to most in academia in that we had about 4 FTE for 3 months - a bit like compressing a “normal” one year grants worth of effort into a quarter of the time. And it was carried out by experienced professionals, not students. I’m aware that some of the deep thought that goes into academic research might need an individual to be engaged with a project for years on end, and that we usually work by training students, but we’ve shown that we can also be productive with a team working in parallel. It would be good to be able to get funding to work in this concentrated way. In some cases maybe we could do more for projects with 2 RSEs working together for a 3 months, than with one at 0.5 FTE for a year? Depends on the project, but we don’t really think about this at all at the moment.