From Trial to Training
Over the last 12 months, we have been developing and standardising our approach to project management and service delivery in the RSE department. We were keen to take an approach that added value for both us and our academic customers. This involved ensuring that the processes and tools introduced provided an element of flexibility to best fit in with the continuously evolving world of active research. Drawing on best practices from commercial software engineering, while also leveraging our knowledge of academic research environments, we have worked hard to develop a lightweight, flexible interpretation of Scrum, which we have now adopted as our standard approach to project delivery.
Upskilling over 40 RSEs was never going to be an easy or quick task. As reported in our previous posts, we developed a workshop, where the technical tasks involved and the product being built were trivial, but where the focus was on understanding and working to our new Scrum process. Working on the feedback we received from the workshop trial, we expanded it into a fully featured 2-day course, delivered in mid-April and mainly focussing on practice with theoretical underpinnings delivered via course pre-reading and a narrated slideshow.
The course notes were all developed using the Software Carpentries template. This enabled a guided learning experience with RSEs split into groups of roughly 6 RSEs focused on 4 different technical stacks. Each group had a facilitator on hand to walk them through the completion of challenges organised into lessons. Each challenge allowed senior RSEs (acting as Scrum masters – leaders of the process) and developers to practise using our chosen tooling of GitHub to complete typical activities within the process. We also finalised our departmental Agile Handbook which acts as the single point of truth for our flexible implementation of Scrum going forward including the use of the GitHub tooling.
The two days were an amazing experience for all involved and one of the rare occasions in this hybrid working environment that we’ve had almost every member of the department in the same room. Several RSEs remarked that just being able to connect with colleagues and work together in a semi-social setting was a welcome change of pace. A second workshop will be run later in 2024 to capture our new starters as we finish up our 2023-2024 expansion with a further 5 permanent, and 3 fixed-term, Grade 6 RSE posts.
What Our RSEs Think
Here is some feedback from our RSEs on the training workshop and the subsequent launch of the new process:
Justin Leung, RSE Trainee: “As a year in industry student working in the RSE department attending the 2-day agile training course, I was able to obtain helpful and informative contents regarding Scrum development. The material provided before the training [was] well informed and straight forward to understand, it helped me solidify key terms, roles and structures before attending the training. Using the scrum development in this training project allowed me to engage in a lot of discussions in various meetings highlighted in scrum development, this allowed me to understand what other developers are working on and build better relationships among scrum master, stakeholders and product owners.”
Chris Fullerton, Senior RSE: “I really enjoyed the workshop. It was very interesting to see how different groups implemented the processes from the course handbook, and what discussions and debates this led to. I’ve been using Scrum for a while, and for me one of the best things about workshops like this is how perspectives from other RSEs let me reflect on how I use Scrum and help me learn some new things. I’ve found Scrum to be an invaluable tool for the kind of complex, evolving software engineering projects we work on in the RSE department. The transparency, focus, and communication it fosters are really helpful. On top of this, I’ve found that what I’ve learnt from applying Scrum to software engineering projects has had a positive impact on many other aspects of my work. This has ranged from how I keep track of all the little tasks I need to do day to day, to how I organise larger programmes of work involving multiple sub-projects. I'd encourage anyone to find out more about Scrum and come to one of our workshops in the future!”
Catherine McGuire, RSE: “I was familiar with the concepts of Agile and Scrum, but the practical (and fun!) nature of this course gave me a chance to see them in action, and understand how I might apply them in my RSE role. In our team, the Scrum framework served as a ‘common language’ promoting more effective communication between different stakeholders, and it helped us to stay focused and complete the assigned tasks more efficiently. It also meant that we weren’t completely derailed by a ‘surprise’ change in requirements! I found the concept of ‘time-boxing’ especially useful in helping me to organise and prioritise my own work and is definitely one of the things that I will try to incorporate when I get back to work.”
Ian Hinder, Senior RSE: “It was really interesting to see how the wider RSE team reacted to the programme we have been developing. We weren't sure what to expect, as most were new to agile, but everyone approached this new way of working with a high degree of professionalism, and wanted to try it out. There were some robust opinions expressed, which gave us a chance to justify the reasons for what we were introducing. There were also many detailed in-depth discussions of the process and the reasons behind it, and not much time for actual coding, but I think the course was the valuable learning experience that we were hoping for. I'm sure there will be lessons learned as we start to apply the process to new projects, and as new "experts" in being agile, I'm sure we will adapt the programme accordingly!”
Nigel Green, RSE: “I have worked with Agile for a number of industry companies before but this course provided a lot of new insights for me. It was great to have time working with other members of the RSE team - something we don't always get to do with small teams and hybrid working! Having the course teach the process alongside the tools was a really good approach, particularly the integration with GitHub for managing projects alongside the code. Having the whole team involved in the training was particularly helpful, both for the insights and perspectives over the two days but also to learn a common structure and language to help us work more effectively together on future Agile projects.”
A New Way of Working for Researchers Too
This is more than just a change of service delivery process for us in Research IT. Research Software Engineering is at its best when we collaborate closely with you, our research community. That involves being part of your vision, your ideas, your challenges and helping you solve them creatively and with quality software. Our new Scrum approach builds in the assumption that researchers will play their role in the process too, using the tooling we bring with us and maybe even joining the Scrum team itself.
You may or may not be comfortable with assuming a formal role in the process but there are plenty of smaller changes to how you work with us that will help with the implementation of the new Scrum process for your projects. Below we summarise some of the key areas that researchers are adapting their behaviour and adopting new tools and techniques.
Requirements, Bug Reports and Technical Dialogue
Before the new process, communication was typically done via email, chat or shared documents where requirements, ideas and bugs were expressed. These mechanisms are inconsistent and were difficult to keep up to date. It required a lot of back and forth over email or chat for RSEs to explore those requirements and bug reports and figure out what needs to be prioritised. If this is happening across multiple channels, that also adds to the confusion.
Now, researchers can be added as collaborators in our GitHub organisation and can add requests for features and bug reports directly to the issue tracker on GitHub. RSEs are notified of the changes and can prioritise and explore the issues on the comments thread where the history is tracked. Issues can be labelled, grouped and linked to better illustrate how work is being planned and ideas developed. If researchers are unfamiliar with GitHub and/or issue tracking, our RSE’s will be happy to assist with getting any requests correctly recorded and prioritised during the regular project meetings.
Progress Monitoring
Previously, researchers and RSE managers found it difficult to consistently monitor what has been delivered and what is planned for delivery at any time within a project due to ad-hoc meetings and “management by exception” approaches. Software was often not distributed to researchers until quite late in the project when making changes becomes increasingly difficult.
Since our introduction of Scrum, we now work in short, timeboxed windows called “sprints”. At the end of every sprint, software (if applicable) can be demonstrated to researchers through their regular engagement with us in a “sprint review” meeting. These reviews allow researchers to see output quickly and regularly and RSEs get feedback early. RSE managers can see what has been done, how much work is planned for the next sprint and the rate at which work is being delivered.
Release Management, Automation and Code Quality
In the past, it hasn’t always been clear what version of the software is being used where, on what systems, when it was developed, or by whom. Furthermore, we have not been consistent at making use of automation for continuous integration (running software tests or style checkers) which has led to code quality being mixed.
We have standardised our Git practices and are now making use of proper release management using GitHub’s release management process. Developing using a GitFlow paradigm using tagging and applying a basic level of automation and peer review for all project now ensures quality and guarantees that if you as researchers want to know what version of the software you have and where it is – we know. If researchers are also acting as developers, we expect them to follow our process too so ensure that changes to the code, wherever they come from, are integrated consistently.
Prof. Caroline Jay and Dr Lukas Hughes-Noehrer of the Department of Computer Science commented on the impact of the new process on their collaborations with the RSE department saying:
Lukas: "Research projects involving a considerable part of software development and several stakeholders can get messy quite quickly if there is no sound project management and structured development environment in place. Using scrum and our Enterprise Github has helped tremendously to keep a clear overview of responsibilities and tasks. Our fortnightly sprint planning meetings further ensure that everyone's workload is balanced and feasible in the set out timeframe. This has improved productivity through setting reasonable goals, making every concluded sprint feel like a great achievement."
Caroline Jay: "Regular meetings to check on technical progress within the team are really helpful. We have benefitted from guidance from a senior RSE in these, helping us to navigate unexpected issues. It is great to have the transparency of the issue tracking too. We now use this across the project, not just for the tasks that the RSE is working on directly."
Dr Patrick Parkinson of the Photon Science Institute also commented:
“I’ve worked very happily with the RSE team in the past. With our most recent project, the introduction of clear progress monitoring and the ability for me to dynamically adjust the priorities helped for me to feel closer to the project development. It's also helped for me to learn more about the capabilities of GitHub for my own work.”
Feedback
If you have any questions or concerns about the on-going changes in the RSE department then please contact the Head of Research Software Engineering directly – we are happy to listen.
If you would like to find out more about the course we have developed and would like us to run it for your research group, contact Ann Gledson.