1. Making Distributed Agile a Success in government:
A Defra case study in partnership with Kainos
Summary
• This paper summarises Defra's experience in operating a distributed agile model in
building the front-end customer portal of the Common Agricultural Policy (CAP)
Information Service
• The key arrangements, benefits, pitfalls and indicators of success are highlighted
• Defra's experience is deemed to have been highly successful when measured by
productivity (team velocity), cost savings, strength of supplier/customer working
relationships and quality of finished product
• We believe that there is an opportunity here for other government departments
building digital services to adopt similar models, or specific elements of such a
model
• The model adopted by Defra may prove more challenging than indicated here,
when scaled up to operate over more than 3 locations/countries and 4 development
teams
What is distributed agile?
• An agile approach to software development where business is conducted across
multiple sites or even countries
• Several teams work together to build a common product
• Software is developed locally and integrated into and tested in a shared online
solution, accessible from all locations
• Teams communicate over internet-enabled audio/visual channels and group
telephony arrangements
Why do it in government?
• Cost savings can be significant, depending on choice of location, cost of labour,
level of investment required in equipment and facilities etc
• In large projects there is often not suitable/available office space for several
development teams at a single site
• It retains the best benefits of traditional agile, e.g. multi-disciplinary, co-located
teams & regular sprint cycles
• But it also embraces modern communications to enable several teams to build the
same product from different locations
The basis of the Defra model
2. Defra are building an online application for 100k+ customers to apply for and receive rural
payments available under the Common Agricultural Policy. Four business/development
teams are located across three sites in three different countries; Reading (England),
Belfast (N.Ireland) & Gdansk (Poland). In addition,
• Teams are a combination of supplier people, civil servants and contractors,
supported by Government Digital Service (GDS) staff
• Each team has a dedicated Product Owner, business analysts, scrum master and
team of developers/testers
• Where possible most team members are co-located
• Primary communication between teams is through chat and video-conferencing
using free, open internet products such as Skype and Hangouts
• Online collaborative tools are used to track and move items through analysis and
development workflows (e.g. Huddle, Mockflow, Github, Mingle). Wikis are used for
software documentation
• All team members have dedicated laptops without government security restrictions
What are the ingredients needed for success?
The following are pretty much essential:
Technology & infrastructure:
• Fast, wireless internet connections at all sites
• Use of internet chat and video conferencing tools on individual's devices and
communal area comm's stations
• Large video TVs or screens and quality audio equipment (mics & speakers etc)
• Laptop or tablet devices without constraining government security protocols
• Online collaborative tools to manage workflow
Teams and people:
• Some business people (e.g. Product Owner, analysts, subject matter experts) co-
located with each development team most of the time (i.e. regularly but not
exclusively)
• Teams consisting of a mix of civil servants and supplier staff. This ensures the right
mix of skills and helps build digital capability and skills in government departments
• Access either directly, or through people at other sites, to users on a regular basis
to test your product and iterate it
• People responsive to and ready to embrace change and continually working to
improve things
• English spoken as the primary language
3. The Government Department:
• Department requires sufficient resources, commitment and willingness to operate
differently
• It will probably need to flex existing IT security policies to allow the appropriate use
of suitable equipment
• It may need to incentivise civil servants (e.g. allowances, temporary promotions etc)
to work on detached duties for regular and sometimes long periods
The supplier:
• Supplier willingness to invest in sufficient facilities, infrastructure and equipment if
using their own sites
• A proven track record in delivering agile projects, particularly operating over more
than one site
• A flexible responsiveness to the client/department's needs and budget
The following are also Desirable:
• Extensive white-walls and/or mobile whiteboards and space to move and gather
around these
• A dedicated meeting room with audio/visual facilities adjacent to main work areas
• Support from the Government Digital Service (GDS)
• International roaming mobile tariffs for departmental staff
What are the barriers to success?
There are some potential disadvantages but many of these can be managed with careful
planning, such as:
• Language barriers – contract with or recruit people with a sufficient grasp of English
(or the preferred common language)
• Different time zones – 1-2 hours difference is generally manageable, but wider
differences are likely to result in decisions being delayed
• Extensive and regular travelling time to ensure people connectivity between sites.
• Long periods without f2f contact or team integration across sites is likely to result in
a drop in performance and efficiency
4. • A shortage of suitable and willing civil servants or contractors to work (possibly long
weeks) away from home
• Poor internet connectivity – prolonged periods of this will significantly prevent
success
• Distance from users – if you have no direct dialogue or opportunity to test the
product with users, you will need regular access to those that do. Building any part
of the product without insight will ultimately lead to failure
• Distance from stakeholders – for business staff located remotely it can be a
challenge to get the necessary stakeholder input into business analysis
Cost savings
The case for cost savings from operating distributed models will be based on a number of
variables, such as the variation in supplier cost of labour and premises across
geographical locations as well as availability of appropriately skilled labour at competitive
prices.
What we learnt at Defra
• Seed the remote team(s) with existing knowledge: To spin-up a new dev. team
who will work remotely seed it with staff already working on the same project. It will
get the new team used to the culture, project details and technology much faster
• Bring your remote team to the heart of the operation for a short time: e.g. send
Gdansk based staff to Reading for a few days. This builds relationships quickly, puts
faces to names and exposes them to the pressure of the project working
environment
• Ensure business people and developers have regular face-time: this is a major
win-win, enabling faster decision-making, regular review of the product and helps
build strong relationships quickly
• Invest in optimum internet connectivity: For the first few weeks of operating one
remote team in Belfast, internet connectivity and bandwidth at the Reading site was
insufficient to conduct meaningful video-conferencing between the two sites. This
led to mis-understandings, frustration and difficulties sharing mutually beneficial
information. When new investment in internet connectivity occurred however, there
was a noticeable improvement in communication quality and far fewer issues
5. • Contacting key people across sites could sometime be challenging:
particularly where some staff made scant use of real-time comm's technology or
were regularly inaccessible. Ensuring your busines people have suitable IT kit to
facilitate video-conferencing is particularly important, so they can participate in
events such as scrum team stand-ups, sprint retrospectives and user journey kick-
off workshops
• Establish cross-team communication forums: e.g. a scrum-of-scrums meeting,
is essential to prevent teams operating in silos. This will also help drive out
innovative ideas and sharing of best practice. Run retrospective sessions across
locations too to achieve this
• Alternating business staff presence between the core development site and
remote locations (i.e. alternate weeks) ensures that stakeholder engagement and
user insight effectively inform any development work conducted remotely
• Scaling up: Moving from one team working remotely in Belfast to adding another in
Gdansk introduced additional communication challenges (e.g. time zones,
connectivity across more locations etc.) but this did not appear to adversely impact
productivity
• Have a central online product backlog: Initially we established duplicate Kanban
boards in each office to manage our product backlog of stories. It proved difficult to
keep both boards up to date simultaneously. As we gravitated to using a central
online repository for user stories (Mingle) this removed the problem, but it also
resulted in reduced white-board work and visual Kanban boards to wrok from. You
need to achieve the right balance.
• Create a dedicated meeting room: The lack of a dedicated meeting room with
audio-conferencing facilities in Belfast initially made it challenging to join and fully
participate in some tele-conferencing and video conferencing collaborations. This
issue barely arose in Gdansk, where such as dedicated facility was provided at the
outset.
How did we measure our success?
6. • Working Software: The production of working software is the ultimate measure of
success. In Belfast, team velocity figures were only fractionally lower (at 9%) after
ten sprints, than the well established teams in Reading. In Gdansk average velocity
figures for the first ten sprints were higher than Belfast's first ten sprints by 10% and
on a par with the Reading teams. See Annex I for further details.
• Defra/supplier relationships were strong at times of pressure. The teams
continued to work cohesively, often going the extra mile to work late when
development slipped against timescales.
• Quality of audio-visual communication and regular sharing of information
appeared to have a direct correlation with the teams connectivity and integrated
working across sites
• Proximity to users and stakeholders: Changes made to the product could
invariably be related back to user and stakeholder insight
Conclusions
Operating a distributed agile model is challenging, hence it is still relatively uncommon. It
relies on commitment and investment in technology, people and infrastructure from both
suppler and customer. There should always be a sufficient level of co-location of business
and development team personnel and readily available access to end-users and
stakeholders. It won't work without high quality audio-visual communications and central
online repositories, forums, workflow tools and product backlog. There needs to exist
proven trust between supplier and customer to support the building and maintenance of
productive and remote relationships.
There are plenty of reasons to consider adopting such a model for future agile IT
development projects being pursued within and across government departments.
We would be keen to showcase our experiences to other government departments and
work closely with Government Digital Service to establish distributed agile as a feasible
model for delivering agile IT development, aimed at providing government digital services
to UK citizens.
Chris Harvey, CAP Delivery Programme, Defra
November 2014
7. • Working Software: The production of working software is the ultimate measure of
success. In Belfast, team velocity figures were only fractionally lower (at 9%) after
ten sprints, than the well established teams in Reading. In Gdansk average velocity
figures for the first ten sprints were higher than Belfast's first ten sprints by 10% and
on a par with the Reading teams. See Annex I for further details.
• Defra/supplier relationships were strong at times of pressure. The teams
continued to work cohesively, often going the extra mile to work late when
development slipped against timescales.
• Quality of audio-visual communication and regular sharing of information
appeared to have a direct correlation with the teams connectivity and integrated
working across sites
• Proximity to users and stakeholders: Changes made to the product could
invariably be related back to user and stakeholder insight
Conclusions
Operating a distributed agile model is challenging, hence it is still relatively uncommon. It
relies on commitment and investment in technology, people and infrastructure from both
suppler and customer. There should always be a sufficient level of co-location of business
and development team personnel and readily available access to end-users and
stakeholders. It won't work without high quality audio-visual communications and central
online repositories, forums, workflow tools and product backlog. There needs to exist
proven trust between supplier and customer to support the building and maintenance of
productive and remote relationships.
There are plenty of reasons to consider adopting such a model for future agile IT
development projects being pursued within and across government departments.
We would be keen to showcase our experiences to other government departments and
work closely with Government Digital Service to establish distributed agile as a feasible
model for delivering agile IT development, aimed at providing government digital services
to UK citizens.
Chris Harvey, CAP Delivery Programme, Defra
November 2014
