An exciting trend in software development celebrates the malleable nature of software.
Agile software development embraces the fact that nobody knows all the functionality, usability needs and problems in software in advance, and proceeds by iterations: small releases every few weeks to inform stakeholder feedback and determine what gets implemented next.
Our project, Hipster, seeks to work with Agile developers. We wondered if we could ‘eat our own dog food’, by developing an Agile Research process. That’s not as silly as it might sound. Agile is not new in research practice; the CyBoK project uses iterative delivery to successfully document a world Cybersecurity curriculum.
Agile is powerful because it is a philosophy rather than a fixed method. There are dozens of different ‘practices’ associated with Agile, ranging from daily stand-ups through pair programming, test first and continuous integration, to project charters. And one of the most important practices is ‘self-organising teams’, who choose their own practices and amend them over time. This flexibility may account for Agile’s massive success; what’s not to like, if you can ignore practices that don’t work for you?
The Agile practices that we chose for Hipster relate to mainly to project management. We define fixed two-week ‘sprints’; we schedule retrospectives and planning sessions around them; and we specify our work in ‘tasks’ of a day or so each. We set up a Kanban board, using Trello, an online service, to manage and track what we’re doing.
At the project planning stage at the start of each sprint, we review what happened in the previous sprint; then create task ‘cards’ for the activities in the coming sprint. We assign cards to researchers, give them categories to ensure we’re not missing out aspects (‘administration’ tends to be under-represented unless we make an effort!). And we assign each card to the backlog for the current sprint, or perhaps to the ‘icebox’ to consider for a later sprint. As we start on each card, we move it into the ‘active’ stream; then as we complete it, to the ‘completed’ stream.
Having a planning session with all of us together, means that the ‘Primary Investigator’, who spends only a few hours a week on the project, can contribute at a detailed level to the project activities and the decisions made. And the two weekly sprints means that the researchers have the deadlines that we academics all seem to need to encourage us to complete tasks!
Looking forward, the next Agile practice to adopt might be estimating the effort required for each task, and using that to limit the number of tasks for each sprint. Task estimation is definitely a new concept for this particular research team, but could make sense. Other Agile practices we could consider are: ‘pair programming’ on project code, or conceivably even pair writing of papers; ‘test first’ in defining outcomes for each task before starting; and, since we’re researching Agile Security, maybe even occasional threat assessments for new tasks!
That's how you get exciting innovations: from taking ideas from one field and using them in another.
Could you do Agile Research too?
- Charles