The WoT as an Awareness Booster in Agile Development Workspaces

Agile methodologies make the development of web applications more efficient. On the flip side, web applications also make agile methodologies more efficient. Just think about issue tracking, source code management and communication. All of these software engineering tasks are now commonly handled via the web, especially in remote teams. Looking at this dual relationship, we see the Web of Things as a particularly interesting web engineering domain. In our research, we are interested by two questions. Firstly, we want to understand how agile practices can be applied to the development of WoT systems. For instance, what does it mean to build continuous delivery pipelines and to implement an automated testing strategy in a WoT environment? Secondly, we want to explore how WoT applications can make agile development teams more productive.

This paper focuses on the second question. We demonstrate how the WoT is a powerful mediation platform for continuous feedback in agile workspaces. We first look at the importance of feedback and awareness in agile methodologies. We then explain how an event-driven middleware provides a foundation for designing workspaces augmented with WoT components. Finally, we illustrate this concept with a usage scenario and a demonstration setup. While space prevents us to give a lot of implementation details, we explain how the APIs defined by the iFLUX event-driven middleware [1] can easily be implemented to connect information sources (e.g. code repositories, quality management platforms, etc.) to physical displays (e.g. Arduino-based devices).

Feedback is one of the most important principles in agile practices, at all levels. Software is developed in short iterations, so that customers can give frequent feedback about the software functionality and user experience. Developers write automated tests, so that they can get frequent feedback about the software quality. Teams do regular retrospective meetings, to capture feedback about their work practices and fuel a continuous improvement process.

The notion of feedback is closely related to the concept of awareness, which as been extensively studied in the Computer Supported Cooperative Work literature. Dourish and Belotti [2] have defined awareness as an understanding of the activities of others, which provides a context for your own activity. In our context, this raises two questions. Firstly, how can we capture the activity of a software development team (what are tasks to be considered? where are these tasks performed? how can we monitor and record them?). Secondly, how can we make this activity visible to the whole team (what are the appropriate presentation modalities? how do we deal with information overhead?).

Agile practitioners have looked at these questions for a long time. The reason for sticking post-it notes and charts on walls is to make information publicly available, thereby giving a shared context to the team. Cockburn [3] has coined the term of information radiators, which should make information easy to read and frequently updated. Information radiators [4, 5] are often low-tech: when status changes, someone needs to update the status with pen and paper. We have often observed a tension between physical and digital boards. Physical displays tend to be more impactful. Digital boards, on the other hand, enable archiving, searching and remote collaboration. This is precisely where we see a huge potential for applying the WoT to agile development workspaces. With the adequate technical infrastructure, it is now easy to create digital widgets that augment physical boards, thereby combining the benefits of both approaches.

The idea of using “smart objects” to display notifications is not new. Many agile developers have hacked lava lamps and sirens to notify breaking builds. Our contribution is to make this process easier. We aim to offer an open and lightweight integration platform for wiring activity sources and information radiators. We want to empower agile teams, who should be able to experiment with new ideas and to integrate custom components. Working with many agile teams, we have seen the value of “making”, “hacking” or simply put “cool” activities. Beyond the immediate outcome of these activities, it is the impact on the team culture and the sense of belonging that is extremely valuable.

The core of our agile awareness platform is the open source iFLUX event-driven middleware. We have initially created iFLUX in the context of a research program on smart cities. However, the middleware is generic and is well-suited for any kind of WoT system. Its programming model was inspired by popular lightweight service integration services, such as IFTTT and Zapier. It follows the Event Condition Action (ECA) paradigm [6] and is based on three core abstractions: (i) event sources, (ii) action targets and (iii) rules. Event sources and action targets are meant to be developed by third-party developers, independently from any specific application (to encourage reuse). Application developers implement workflows on top of available event sources and action targets, by defining stateless rules. Essentially, they express rules such as “if an event with properties that match these conditions is notified, then trigger an action on this target, with the following properties”.

For illustration purposes, let us consider two important facets of the software development activity and that the team should maintain awareness of:

• awareness of team activities. When people share a physical space, they unconsciously process audio-visual cues (e.g. body language, side conversations) and have a general sense of what others are doing. The situation is different when people do most of their tasks in digital systems (e.g. in a code repository), or when they work remotely.

• awareness of software quality. The goal of an agile team is to deliver working software. It is therefore critical for the team to keep track of what measures software quality: passing and failing tests, feedback from users, number of issues, etc. This information must be extracted from different systems.

4.1 Capture Information with iFLUX Event Sources

Creating a source of information with iFLUX is easy. The middleware exposes a REST endpoint (/events). Event sources POST simple payloads, with an event type, a timestamp and a list of custom properties. Consider two examples:

• an agent, which uses the GitHub API to monitor events occurring in the code repository such as commits, pull requests, comments, etc. The agent issues POST requests to forward GitHub events to iFLUX.

• an agent, which fetches information in the Probe Dock agile testing platform. The agent emits iFLUX events whenever a suite of automated tests is run (indicating the number of failing tests). The agent also emits events when new tests are added to the test suite.

4.2 Represent Information with iFLUX Action Targets

Creating information radiators with iFLUX is also easy. When a rule is triggered, the middleware issues a POST request to the URL declared in the rule. Creating an information radiator means implementing a /actions REST endpoint. The endpoint has to process JSON payloads, which also have a simple structure: an action type and a list of custom properties. Consider two examples:

• a custom device, built by integrating an Arduino board with a color LED ring. The embedded HTTP server accepts JSON payloads. The payloads have an action type property with the value setColorPattern and a custom property pattern with one of the defined values (e.g. solid-green-bright).

• an analytics dashboard, built as a web app displayed on a large public display. The web application maintains the state of various metrics and exposes the /actions endpoint. It accepts payloads where the action type property has a value of updateMetric and where the id and the value of the metric are specified in custom properties.

4.3 Connect Sources and Targets with iFLUX Rules

The iFLUX components are loosely coupled. The LED display can be used to represent activity happening in any of the connected event sources. Similarly, activity detected in the GitHub space can be represented in any of the connected action targets. Once the sources and targets have been implemented and deployed, it is up to the development team to define event-condition-actions rules. They do that by posting payloads on the /rules endpoint exposed by the iFLUX middleware. A first rule could specify that” if the event type is probedock.testRun and the custom property numberOfFailures is greater than 0, then send an action target to the LED display with the action type set to setColorPattern and the pattern custom property pattern set to pulse-red-fast. Another rule could specify that if a new commit is detected in GitHub, the LED light should blink twice and the metric numberOfDailyCommits should be increased in the analytics dashboard.

We have shown how the iFLUX middleware facilitates the integration of various event sources and information displays, and thus the creation of informative workspaces. We have used such WoT installations in different agile environments. We have witnessed the value of making team activities and software quality continuously and physically perceptible. Something as simple as knowing that new code has just been committed may not seem very helpful. But we have observed that it positively impacts the team dynamics. More information about iFLUX is available on http://www.iflux.io.