The Met Office Weather Observations website (WOW) project has created a crowd-sourcing application allowing the general public to submit weather data to the Met Office. This application was the first IT project carried out for the Met Office to use the scrum agile development approach and also to place its software and data on a cloud platform.
Since 1854 the Met Office has been the public body with responsibility in the United Kingdom for forecasting weather. Although with a global reputation, today it has some private sector competitors such as MeteoGroup. To carry out its mission, the Met Office has IBM supercomputers at its HQ in Exeter which process data collected from a large number of weather stations.
Weather stations can vary in size and sophistication. Some are completely automated, some use traditional human recording methods with various degrees of automated and manual operation in between.
Perhaps surprisingly the observers who supply the weather data are not employed by the Met Office. Some are the staff of organisations with a particular interest in weather conditions such as the armed forces, air traffic control, coast guards and researchers in universities, as well as trusted individual enthusiasts.
There are many other weather enthusiasts, including schools, who collect weather data. This data could be very valuable, but the Met Office until recently had no way of utilising it, although there were other organisations outside the UK such as Weather Underground that catered for weather enthusiasts.
Since July 2011 the Met Office has had its WOW (Weather Observation website). It now has over 3,000 contributors and deals with a million new data points a week. This is crowd sourcing with a vengeance.
A question naturally arises of how far you can trust the data? However, the great thing about networked communities is that they can be self-policing. Web-users can record their doubts about the data presented by a website. For example, if rainfall has been recorded in their locality, but they have experienced a sunny cloudless day.
The data supplied by the WOW community has been compared to that from conventional sources and been found to be consistent. Indeed the WOW data may be more accurate because of greater frequency of the readings.
Members of the public can submit weather data in a number of ways, with differing levels of sophistication. This means that participants can range from children in primary schools to enthusiasts who have invested time and money establishing and maintaining a near-professional weather station.
‘Quick observations’ allow you can submit a one-off observation, which at its most basic level could be a simple identification of what is happening at particular time and place, for example, ‘some clouds in sky’. A photograph can be attached to this.
‘Detailed observations’ caters for observers who can submit data on a regular basis, for example at 9.00 each morning. Typically these would be based on manual measurements using instruments housed in a traditional Stevenson Screen (invented by the father of Robert Louis Stevenson of Treasure Island fame).
Finally, there are automated observations. It is now possible for hobbyist to buy electronic weather measuring instruments that can be linked to the web via a wireless connection to a PC.
The Met Office commissioned PA Consulting to implement WOW. It was agreed that, for first time, an agile Scrum approach would be used to develop a Met Office application. Scrum is an agile method originally developed for product development projects, but has become increasingly used in the development of software, which, after all, can be seen as just another type of product.
In scrum, the development team is expected to be largely self-organising, under the guidance of a scrum master who acts as a moderator. PA Consulting’s Paul Craig, who recently gave a presentation on WOW to the Project Management Specialist Group (PROMS-G) of BCS, took on this role.
The scrum approach tackles the usually time-consuming task of gathering and prioritising user needs by identifying an individual who has authority over the features of the system to be built. This person is in scrum language the product owner. With WOW, an experienced Met Office project manager, Charlie Ewen, took this role.
In his talk to PROMS-G, Paul Craig stressed the crucial role of the product owner, particularly where the client organisation uses formalised, bureaucratic procedures to control projects, such as those enshrined in PRINCE2.
Despite some spirited attempts to argue that the PRINCE2 can be used to control agile projects, there are large cultural differences between the two approaches. The product owner has to have the patience and flexibility to bridge these two different worlds.
Paul Craig made it clear: ‘Agile scrum is only as good as the product owner’.
With WOW, the scrum team consisted of four software developers and a full-time systems tester. Communication with the user community was not only through the product owner. A user experience specialist liaised with client representatives about the details of interface design.
Scrum encourages a ‘get stuck in approach’, which is an anathema to conventional project management that focuses on careful planning up-front. With scrum, the product owner secures the resources for the project then identifies the features of the product to be built, allocating a relative business value to each one in a product backlog document.
The functionality is then developed in a series of sprints of about two to four weeks each. At the start of a sprint, the product owner and the development team meet and examine the initial product backlog. Starting with the highest priority requirement, the product owner explains each one in turn. The tasks needed to implement the items on the product backlog for the next sprint are recorded on a sprint backlog.
Work now starts. Each day the scrum team has a stand-up meeting of around 15 minutes. Team members have to firstly report what they have done since the last meeting, then what they plan to do before the next meeting and what obstacles might hold them up. A burn-down chart is updated and published daily showing the actual amount of work (as estimated staff effort) remaining.
The sprint finishes with a sprint review meeting where the scrum team presents the product owner and other interested stakeholders with the products created. In the light of the review, the product owner might change the product backlog, adding, amending or removing requirements.
The scrum master may also hold a sprint retrospective with the development team to review the lessons of the last sprint and identify process improvements. If there is another sprint to be carried out, the next sprint planning meeting now takes place.
A circumstance that helped the WOW project was that it was, initially at least, a standalone system. A potential problem is that if you are asking volunteers to supply information and you do not want to turn people away, you cannot accurately forecast the demand that might be put on your server infrastructure. The answer was a cloud computing solution, which seems appropriate for the Met Office.
No dedicated hardware/software platform was set up for the application. Java applets were developed and uploaded to the platform supplied by Google Application Engine. This was very cost effective as you only paid for what you used. These services can be offered cheaply because of the large economies of scale and a focus on essential requirements rather than ‘frills’.
Some knowledgeable participants at the presentation commented that a cheap service often means scanty support. This poor support for commoditised services has led to the growth of mutual help groups such as those who inhabit www.stackoverflow.com, an information exchange forum collaboratively built and maintained by software developers.
There were some concerns about cloud-based development. Security could be a problem, but worries are reduced by encrypting data before uploading. Even so there could be data protection requirements about the storage of personal information about observers.
Where personal details about individuals are concerned, the actual physical location of the servers will be important as compliance with data protection legislation requires that personal data be kept in countries that comply with the UK/EU laws. In the case of WOW, the answer to this was to store personal data on an internal Met Office system.
Paul Craig noted that as soon as there was interaction with existing Met Office systems, progress was slowed as people were naturally concerned with the possible impact on existing, often critical, functions.
I have already mentioned Paul Craig’s comment on the crucial importance of the product owner in a scrum project. Other lessons learnt from this project included:
- Despite the ‘get stuck in’ mentality, at the start of the project time is needed to ensure a common understanding by participants of what the project is really about.
- People new to agile approaches need to be coached and encouraged
- The technologies themselves are rarely the problem
- Successful agile projects have an effective continuous integration process whereby the consistent interactions between components being developed in parallel are tested on a daily basis
- Try to avoid changing the management tools during execution of the project.
An agile approach to software development projects is not always the best one. It seems to work best in green field undertakings where everything is being built from scratch and developers do not need to worry that changes to critical systems already in use may have unexpected and undesirable outcomes. However the Met Office WOW project shows that in the right circumstances it can successfully meet objectives.
