Message-ID: <965776861.286.1448915890141.JavaMail.confluence@ece-vmapps> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_285_445474729.1448915890140" ------=_Part_285_445474729.1448915890140 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
(Prepared by Thérèse Lalor and Steven Vale - Septe= mber 2013)
The idea of holding sprint sessions to develop standards for official st= atistics is fairly new, but already it seems to have a lot of promise. This= approach can considerably reduce development time (and probably cost =E2= =80=93 but hard data on this are not really available). This note sets out = the experiences and lessons learned from the five sprint sessions held to d= ate, in the context of projects overseen by the High-Level Group on the Mod= ernisation of Statistical Production and Services (HLG). It also makes reco= mmendations for the conduct of future sprint sessions in the context of sta= tistical standards development.
What is a sprint?
The idea of sprints comes from the =E2=80=9CAgile=E2=80=9D approach to s= oftware development. A sprint is generally defined as =E2=80=9Ca =E2=80=98t= imeboxed=E2=80=99 effort=E2=80=9D, restricted to a specific duration, norma= lly between one week and one month, with the goal of delivering a pre-deter= mined output. This means that in the official statistical community, a spri= nt can be explained as being something like a very intense and focused work= shop.
During a sprint, participants break down the task to be accomplished int= o small components, each of which can be resolved in one or two hours by a = small group of two to five people. This means that sprints involve a lot of= parallel working, and that one person can not be involved in everything. T= he aim is to build on the best ideas and experiences of all participants to= reach an outcome that is =E2=80=9Cowned=E2=80=9D by all. This outcome is s= eldom exactly the one envisaged at the start of the sprint, as ideas should= evolve through the sprint process, however, it should be at least as usefu= l, and probably better as a result.
The first two HLG sprints (in Slovenia and the Republic of Korea) were t= wo weeks long, whereas the other three (Netherlands, Canada and Italy) have= been completed within a week. Both types met their goals. Some participant= s to the two-week sprints felt that they were rather slow to get going, so = for later sprints much of the introductory material was covered in pre-spri= nt web conferences. This meant that the participants felt they were startin= g the real work from day one. Some participants, particularly those with fa= mily responsibilities, also felt that two weeks is rather a long time to be= away from home.
Changing to one-week sprints did, however, put more burden on the sprint= team, requiring much more pre-sprint and post-sprint work to compensate fo= r the more limited time available during the sprint itself.
The optimal duration of a sprint therefore depends to a large extent on = the newness of the topic, the prior level of understanding of the sprint pr= ocess by participants, and the familiarity of the sprint master with the to= pic and the issues to be discussed.
Venue and facilities
The ideal set-up is to have the exclusive use of at least three rooms fo= r the whole duration of the sprint. To save time, it is preferable that the= se rooms are located close to each other. At least one of the rooms should = be large enough to comfortably accommodate the whole group seated at desks,= which should preferably be organised in a U shape, facing a screen for pre= sentations. All rooms should be equipped with whiteboards, flip-charts and = writing materials, and ideally it should be possible to stick posters and f= lip-chart sheets on the walls. Plenty of stationery, particularly paper, pe= ns and post-it notes should be available. WiFi Internet access is important= , along with easy access to an on-line collaboration space, e.g. a wiki. Pa= rticipants should bring their own laptops / tablets. Finally, to save time,= it is helpful if coffee and lunch facilities are available close by.
Travel and accommodation
For the HLG sprints held so far, the vast majority of participants have = paid their own travel costs. In just a handful of cases, where people were = considered essential and there was no other way for them to attend, project= funding has been made available to subsidise their costs.
From a practical point of view, it is very useful if all participants st= ay in the same hotel during the sprint. This helps build the team spirit, a= nd facilitates discussions in the evenings and over breakfast. It is helpfu= l if the hotel has a public seating area where people can work in small gro= ups. It is very helpful if someone from the host organisation can help to m= ake local arrangements and advise on practical matters such as travel betwe= en the airport, the hotel and the sprint venue, including where and how to = buy tickets for public transport.
Selecting the participants
Ideally a sprint should have 10-15 participants. If there are more, it i= s difficult to maintain a sprint atmosphere and to get people to work as a = single group. Normally there should be no more than two participants per or= ganisation, to ensure that as many organisations as possible can be represe= nted. Participants should come from a range of backgrounds, and, between th= em, should have all the necessary skills and experience to produce the outp= ut. For HLG sprints, participants have been mainly at the =E2=80=9Cexpert l= evel=E2=80=9D, and have included methodologists, IT specialists, metadata e= xperts, business / information architects and external experts, depending o= n the topic.
Ideally there should also be representatives of =E2=80=9Cthe business=E2= =80=9D, i.e. subject matter statisticians. In practice it has proven diffic= ult to achieve this, as organisations are more interested in spending money= to send =E2=80=9Cspecialists=E2=80=9D as participants. Two possible soluti= ons are to try to select =E2=80=9Cspecialists=E2=80=9D who have previously = worked in statistical subject-matter areas, and to ask the host organisatio= n to make subject-matter people available for consultations if necessary.= p>
Selection of participants for HLG sprints has typically been a mixture o= f nominations from interested organisations, with targeted follow-up by org= anisers to ensure key people and skills are present.
Building the team
In most cases, sprint participants already know a few of their fellow = =E2=80=9Csprinters=E2=80=9D, but it has never been the case that everyone k= nows everyone else beforehand. For this reason, it is important for the spr= int facilitators to try to create a team spirit as soon as possible. This s= hould start already in the pre-sprint web conferences, where participants s= hould introduce themselves, and ideally use a web-cam.
Encouraging participants to meet for dinner the evening before the sprin= t starts can be a useful way of helping them get to know each other in a le= ss formal environment before the real work starts. Ensuring a good mix of p= eople in the small teams for the first few rounds of tasks within the sprin= t can also help.
One important sprint rule is that there is no hierarchy within the sprin= t, all participants are equal, and all views are valid. This can be a chall= enge if an organisation sends two participants, one of which works for the = other.
A particular challenge is how to incorporate the representatives of the = host organisation in the sprint team. Ideally, for the duration of the spri= nt, they should consider themselves out of the office, in a similar way to = being at a meeting in another location, rather than just a regular day at w= ork. They should realise that being a sprint participant is a full time com= mitment, and they shouldn=E2=80=99t try to do their regular job as well dur= ing this period, and should advise managers and colleagues accordingly. The= y should also try to join the group in the evenings if possible.
From experience during the HLG sprints, it is essential to have two spri= nt facilitators. One should take the role of being =E2=80=9Csprint master= =E2=80=9D, whilst the other should take on more of a support and documentat= ion role. However, both should be capable of steering group discussions tow= ards agreements and solutions, resolving conflicts, and stopping people dev= iating from the sprint goals. It is therefore essential that the facilitato= rs should project confidence and authority, and be able to manage the group= . They should also be constantly aware of group dynamics and try to identif= y and resolve any potential problems before they escalate.
On the other hand, it is the sprint group that decides the priorities an= d contents of the outputs, and takes ownership of the working processes to = reach its goals. The facilitators should therefore be careful that they are= not steering the contents and imposing their views. In this respect, it is= helpful if the sprint facilitators are not experts in the topic, although = some background knowledge is useful to be able to follow the conversations = and issues. Some training in facilitation techniques or significant practic= al experience in delivering inter-active training courses is useful for thi= s role. The facilitators need to have a sound understanding of the project = goals.
Documenting progress, decisions and outcomes is very important. The spri= nt should normally result in a paper or report of some kind, and it is much= easier to start putting this together, at least in outline, during the spr= int, than to try to write it from scratch afterwards. To facilitate this, p= articipants should be encouraged to write up the conclusions of their discu= ssions and post them in a common work space such as a wiki, for others to c= omment, and for the facilitators to incorporate them into the overall docum= entation.
The facilitators should both have cameras, and should make sure that the= y take photos of all whiteboard or flip-chart diagrams, as these may be use= ful later to illustrate key points in the documentation.
Before the sprint
Planning a sprint typically takes around three months, with the work bec= oming more intensive as the sprint approaches. The first steps are to secur= e top management support for the proposed sprint, choose a sprint-master, f= ind a location and determine the budget. After these pre-requisites are in = place, a call for participation should be launched and circulated to key pe= ople (managers and potential participants) in the target organisations. Thi= s call for participation should make it clear that it may be necessary to l= imit numbers, and should explain what a sprint is, and how it is different = from a traditional workshop or seminar. It is often necessary to state clea= rly that papers and PowerPoint presentations are not required!
In preparation for the first sprint on a particular topic, the sprint ma= ster or organising team should consult key stakeholders about their expecta= tions for the scope and outcomes of the sprint. This consultation should in= clude a range of levels, from top managers to experts, and a wide range of = organisations, not just those expected to send participants to the sprint. = The summary of this consultation process provides a clear view of the expec= tations of the statistical community, which is a very useful starting point= for pre-sprint discussions with participants.
The sprint master should also use the pre-sprint period to research the = topic. The aim is not to become an expert, but to have enough knowledge to = be able to create the first inputs for the sprint team. It is easier for th= e team to start with something other than a blank page, even if the final o= utput is something completely different.
At least three pre-sprint web conferences are essential, both to help th= e participants to get to know each other, and to cover all the basics about= how a sprint works. It is helpful if participants outline their background= s, ideas and expectations for the sprint, so that some degree of consensus = can be reached before they physically meet.
During the sprint
Most HLG sprints have been opened or addressed by the head of the host o= rganisation. Active interest from this level can help to inspire participan= ts. Towards the end of each sprint, a presentation is usually given to the = staff of the host organisation. This serves several purposes, but mainly he= lps the participants to focus on how to communicate their work, and explain= it to people outside the sprint group.
After any introductory material, the first task of the sprint team is to= create a work plan covering the duration of the sprint. During the sprint,= it is essential to monitor progress against the work plan, and towards the= expected outcomes. A short plenary session first thing every morning is us= eful. This can review what has been done, and what remains, and to decide o= n the priorities for that day. A useful addition to this session is the ide= a of =E2=80=9Csoapbox=E2=80=9D presentations. These are opportunities for p= articipants to present briefly (i.e. in 2-3 minutes maximum) any issues the= y think are important. =E2=80=9CSoapboxes=E2=80=9D are often a good opportu= nity to share ideas from informal discussions the previous evening.
Participants then break into small groups to discuss and resolve the pri= ority issues. These groups are usually self-selected, but some mixing of pa= rticipants by the facilitators can be useful to ensure the same people are = not always working together, and to ensure the group dynamics are maintaine= d. Small group discussions should typically last between one and two hours,= and have a clear deadline. The facilitators should check each group period= ically to see if the deadline will be met. The small groups briefly report = their outputs in plenary sessions. Typically about 70-80% of time is spent = in small groups and 20-30% in plenary sessions.
If a group wants more time, or is struggling to resolve a particular iss= ue, several options are possible:
During a sprint, participants tend to get very involved and enthusiastic= , wanting to share their views and ideas. For this reason, sometimes in sma= ll groups, but always in plenary sessions, it is useful to have a clear way= of asking for the floor. In HLG sprints, participants are given different = coloured objects. They hold up one colour if they want to speak, another if= they think the speaker is going into too much detail, and a third if they = think the discussion is going off-topic.
Finally, a good tradition that has developed at HLG sprints is to ask al= l participants to bring snacks from their home countries for coffee breaks.= This creates a non-work topic of conversation, which helps people get to k= now each other better.
After the Sprint
The main task in the immediate aftermath of a sprint session is to trans= form the sprint outputs into the final versions of the sprint documents. Du= ring a sprint, there is only really time to capture ideas and outlines, but= these need to be expanded and made understandable for a wider audience. No= rmally at least a week is needed for this, usually involving the facilitato= rs and some participants (particularly the Anglophones!).
Another important consideration, which should ideally be planned beforeh= and, is how to capitalise on the momentum developed during the sprint. A ne= w (and hopefully strong) network of experts has been created, and can be us= ed to further the wider aims of the project. The precise follow-up actions = will depend on the nature and stage of the project. In HLG projects, the ap= proach of linking the idea of sprints with short-term virtual task teams th= at meet frequently over a given period to make further progress, has been s= uccessful.
It is also useful to take stock at this point about the organisation of = the sprint. What worked, and what should be done differently in future?
Sprints have proved very valuable in the context of the HLG projects. Th= e Generic Statistical Information Model (GSIM) Development Project was comp= leted within a year, which is less than half of the time taken for comparab= le initiatives using more traditional methods. There is a cost, both in mon= ey and time, but feedback from chief statisticians so far is that the value= of the outputs more than outweighs the costs.
Whilst sprints are probably not the best approach in all situations, the= ir value in the development process for international statistical standards= seems to be confirmed.