Supporting bespoke VLE and external applications means communication and working with others is a key part of my day to day role. Whilst acting as 1st line support, I am one of the first to see new functionality requests from our customers. Working closely with developers within an agile environment means I act as the intermediary between the programme teams and developers. New change requests are likely come from an academic e-facilitator into the support inbox. These tend to be short one line requests that require more research. I check to see what would be involved; what might be affected by any system change and gather more information on when the functionality is required for. This then gets passed to the developers, including the supporting information I’ve researched, making it easier for them to see where the development fits, and whether it is achievable. From experience, the more information that the developer has at the beginning the better. It allows for a better judgement call and is also more efficient, as I don’t need to go back and forth to the customer asking additional questions and relaying information.

We use a number of systems for communicating system changes. All changes and work are recorded using the Atlassian JIRA software. Fig. A shows a list of ‘tickets’ that I have created on the back of requests for change from an academic e-facilitator. It is a useful tool to manage tickets, and to make others aware of the change. At times some requests require to be broken down into a number of smaller tasks. Fig. B shows an example ticket which I have created and included further information for the developer.

One example of this was meeting with the evaluation of teaching team within an undergraduate programme. They sent a very detailed word document containing new features and amendments to our existing questionnaire tool. I organised a suitable time for them to meet up and work through the document and discuss their proposed changes whilst looking at the VLE together. This was a useful session as with my knowledge of the way the platform has been built, I could suggest small changes to their initial requests, and make them aware of which tasks would take longer for the developers to action, allowing them to plan around these. The outcome of this discussion allowed me to create a number of smaller, prioritised tasks, that I could then discuss and assign to the relevant developer, using Atlassian JIRA.

Fig. C contains the email conversation between myself and the academic team representative Sheila, after our initial meeting, discussing and confirming the priorities of the changes discussed.

As well as communicating with the end user via email and creating a line of communication to the developer(s) via Atlassian JIRA, the team have recently begun to use Slack; a tool that allows for asynchronous open group communications and private direct messages. This allows for better organisation of our team conversations, and by using separate channels for specific projects or teams, everyone has a transparent view of what’s going. With the evaluation development example discussed above, once communications have taken place with the customer and the developer, I would post a quick line to the relevant Slack channel, so that everyone involved is kept up to date; either a link to further information, or a short piece on what has been proposed (See Fig.D for an example notification sent to the open channel ‘Exams’, notifying the team that future exam logins had been setup).

Once new functionality and/or processes are available, I am keen to give other members of the team as much information as possible, whether that be through a short step-by-step guide on the wiki, or communicating changes at our weekly team meeting. One example of disseminating new processes via the wiki comes in the form of when a new member of the wider team recently began to assist supporting our services. I created a separate page for an issue we’re aware of but as yet there has been no resolution (See Fig. H). This page includes a sample query from a user, technical history about the problem, and the steps we need to take to resolve the issue for the user. Being able to provide as much as information as possible allows the new team member to resolve queries efficiently whilst gaining an understanding of the systems we build and support.

Outside of the development team, users and the wider University community, I am a keen follower of a number of mailing lists, including ALT, HEFCE and University communities. Whilst I don’t actively participate in discussions, I take a passive approach in viewing the content being shared. One of these was a recent discussion surrounding captioning video content; at a time when I was working on creating guidance videos for an online programme. It was interesting reading the views of others, from both an educational developers viewpoint (and their preferred workflows) to academics using the materials for teaching.

When I was part of the Turnitin service team, I had access to the Turnitin UserVoice community, a feedback forum for its customers, allowing for ideas to be shared and voted to be considered in future service releases. My evidence for this comes in the form of screenshots of the UserVoice ideas list, and my feedback related to an idea previously shared, which is now under consideration with the vendor (See Fig.E and Fig F).

This community of improvements allows us as service team to view other institutions current issues with the system. Whilst attending the 2016 Scotbug user group conference (see Fig. G) it was useful to hear from Turnitin regarding its future direction, at a time where it was releasing a new interface, and speak will colleagues from other institutions. Hearing from colleagues elsewhere allowed me to understand and confirm our institutions’ experiences, frustrations with the service were felt elsewhere, and collectively we can work with the vendor to improve the service, through continual dialogue at conferences and through the UserVoice forum. Going forward I intend to attend user groups/conferences relating the services I am involved with. Meeting peers from other institutions is useful not only in agreeing on system frustrations and limitations, but sharing workflows and ideas that are being used to enhance the student experience in respective Universities, which can then be disseminated to areas within our own community.

Evidence

Fig. C: Software development changes email chain – prioritising changes