Building Responsive Telescope: Feedback, Feedback, Feedback

Auke Klazema (ASTRON, The Netherlands) - ASTERICS Work Package 3

LOFAR Responsive Telescope allows external events to trigger an observation that gets scheduled as soon as possible. It has been on the wish list from the beginning of LOFAR and finally, in November of 2016, the first code changes were written. This marked the beginning of the building of the Responsive Telescope.

A group of six ASTRON developers were asked to work on it. The group consisted of mostly software support developers, which meant that members could not solely focus on the building the Responsive Telescope, but also had to support LOFAR when something goes wrong. The group was asked to use the Scrum framework during their development. This process sets a few events and roles that would ensure that the software that gets build is what the end users wants. This is not always the way things are done in the software industry. The Scrum events gave us many small feedback loops that kept us on the right track.

The events consist of planning meetings, daily progress meetings, review meetings and retrospective meetings. These events make sure that there are many opportunities to check if the team is still working on the right tasks. If this not the case anymore it is noticed early and changes can be made. These feedback loops were key in bringing Responsive Telescope into production before the planned use.

The roles consist of Product Owner, Development Team and Scrum Master. The Product Owner determines what functionality is needed. One way of specifying this is through user stories that define a basic functionality in one or two short sentences. The Development Team consists of individuals with different skill sets.

The team is self-organizing and is responsible of determining how many tasks can be finished in a certain period and how. Finally the Scrum Master makes sure that the Scrum framework get used correctly through education and is responsible for setting up all events.

All of the work gets done within what Scrum calls Sprints. This is a short period of two to four weeks. We used three week long Sprints. Before each Sprint the Product Owner determines the priorities of all the user stories. This way there is always an option to change ideas and functionality wishes. During the Sprint there are daily meetings to see if the team is still on track. Because the entire team is responsible for finishing all the stories committed to it, it is good to know if an individual is stuck on a problem. At the end of a sprint a demo is given to the Product Owner and other stakeholders so feedback can be given on what was created.

If the Product Owner likes what was created the software can be put in production. If not, the team knows it early in the development cycle and only lost a short amount of development time. Finally, the team sits down to see what went right and what not during the sprint. The team can then decide to improve something during the next sprint. Having a Product Owner available when the Development Team has a question is a key for a successful project.

During the development of Responsive Telescope the Development Team had to make some technical choices that would limit some of the wishes of the Product Owners. But this would result in delivering more functionalities. Sometimes some wishes took more time than expected and being able to communicate this early helped the Product Owner as well to reprioritize their wishes. They could also get a feel for what it would take to make a certain change. Sometimes it meant that they would get less functionality, but sometimes also more. It also helped the Development Team to make suggestions to get more flexibility on the instrument by trading in some requested way of working.

This process of continued feedback and communication helped a lot in the building Responsive Telescope. It kept the team focused on the right things. An example of feedback within the team was that in the beginning everyone worked on their tasks whenever they could. They still had many meetings already planned. They did have their daily stand-ups so they could communicate their successes and difficulties. But there was not a lot of time overlap otherwise. This was discussed within the team and it was decided that more overlap should be found to increase discussion opportunities by shifting around agendas to get more overlap.

In the beginning the work was mostly about making sure changes could be made without breaking existing functionality. Later it was possible to add functionalities that could stop already running observations. Then validate if trigger specifications were correct. Next, add priorities to projects and being able to mark if triggers could be used by the project and how many. Create a website were project members can log into to see the current status of their triggered observations. And finally the system needed to know what to do with triggered observations.

During our development the Development Team wanted even more feedback. So they added more in the form of automated tests. Then whenever new changes were added tests could be run to see if all previous changes were still working. By monitoring when new parts of the system were introduced on the tests environment, they could see when something went wrong through process monitoring, logs and emails.

In the end the Development Team supported three types of observations for the first version of Responsive Telescope. There is also an option to specify an observation window during which the observation needs to be done. This allows us to schedule a trigger a bit later than “as soon as possible” if a higher priority project is almost finished. If that option was not included, more observations than needed would have to be rejected.

So we hope that LOFAR has been made a bit more interesting, from a scientific point of view, and with feedback of it usage we can add even more functionalities in the future.