Smoothing the Transition from Agile Software Development to Agile Software Maintenance

Kainos [1] is a public limited software company, established in 1986 and based in Belfast, Northern Ireland. It develops information technology solutions for businesses and organizations, particularly in the public, healthcare and financial services sectors. The company also provides consulting and support services. Kainos has offices in the UK, Ireland, Poland and the US, operating across Europe, the Middle East, Africa and North America. It has grown rapidly in recent years, with employee numbers of 260 in 2010, 350 in 2012, and now over 750 in 2015, of whom approximately 490 are engaged in development and 95 in service support (maintenance).

Roughly, three-quarters of the work in the Service Support Department is concerned with software developed by the company. There are several major projects, however, where development took place elsewhere. In such cases, there is a significant challenge in taking on the software in a way that is relatively seamless for the client. The central concern is knowledge acquisition, with the goal being to build an understanding of all aspects of the software without any adverse effect on the service provided in the transition period.

The paper focuses on the situation where a client has had an agile way of working during development and wishes to work with Kainos using the same process during maintenance. The experience of a specific project with the UK Government Cabinet Office is described. This is preceded by background information on agile practices within Kainos.

The introduction of agile techniques at Kainos started with development. This began in the late 1990s with the introduction of DSDM, but has subsequently been overtaken by the use of Scrum. As noted in surveys carried out in 2010 and 2012 [2], the use of an agile approach in the company was mostly dictated by the requirements of each client. At that time, this did not include the public sector part of the business. Now, however, following a strong government commitment to agile practice in public projects [3], roughly 70 % of the work at Kainos is currently agile-based.

The use of agile techniques in the Service Support Department is a relatively recent innovation, starting in 2013. Like software development, this has largely been client-led. Because of its significant involvement in the public sector, maintenance practices in the company are ITIL-based [4], with ISO20000 IT Service Management accreditation [5] awarded in 2009. As a result, all aspects of the maintenance process are defined in detail, and audited for conformance annually. The process definition includes the role and content of Service Level Agreements (SLAs) and the provision of specific services, such as a Service Desk and the management of incidents and third-party suppliers. The transition process from development to maintenance is also specified and this will be considered further in the next section. Overall, the resulting process has proved very effective, for both Kainos and its clients.

The Service Department at Kainos supports over 80 clients. Each client has an assigned service manager and an engineering team, the composition of which varies according to need. There is also a more senior group of service delivery managers who handle the commercial side of the work, including competition for contracts, contract agreement, and the pricing of new work as it emerges.

Conceptually, the engineers form a single pool of staff, where often each engineer will work with several clients simultaneously. Because of this flexible structure, and a focus on responding quickly to client needs, agile techniques were first introduced through Kanban, supplemented with selected Scrum practices. The approach was based on the three key elements of Kanban identified in [6]:

Each Kanban board was set up for the clients associated with a specific client manager. All boards started with the same base process but the associated engineers were encouraged to adjust them as they saw fit, in line with Kanban principles. As with any innovation, this worked best where a ‘champion’ emerged to lead the initiative. Where possible, daily stand-ups were used to review progress with client work and, initially, reflect on the effectiveness of the Kanban approach.

As well as refining the structure of each Kanban board there was also a need to align its content with an existing Kainos Incident Management system (KIM), where clients report issues or make requests for change. KIM held all of the information associated with each work item. The Kanban cards simply recorded KIM references and brief summaries of the tasks involved. Aligning these parallel descriptions required discipline and, for most engineers, felt unsatisfactory. Another difficulty was that some engineers occasionally worked offsite, which meant they couldn’t see the board or keep it up-to-date with their own activity. To help address both problems an electronic Kanban system, KanbanFlow [7] was introduced in early 2014 and the physical boards replaced by electronic screens. To retain most of the benefits of the original boards, each screen was dedicated to representing the board it replaced. Since then, the only change has been to switch from KanbanFlow to Trello [8], because of its adoption as the general agile support platform within Kainos.

Kainos has experience of all three types of software transition [9]:

One significant example of self-to-self transition is Evolve [10], its electronic medical records system, which currently has 29 Healthcare Trust clients across 70 hospitals in the UK. As a major product, Evolve has a pool of dedicated staff responsible for its promotion, deployment and support. This includes: (i) a client-facing analysis team who work with each new Trust to identify its specific requirements; (ii) a back-end technical team who handle the implementation and deployment of each instance of Evolve, together with the ongoing enhancement of the base product; and (iii) a support team with the maintenance role of responding to client incidents and their requests for change. All of this work is managed using Scrum.

Roughly 75 % of the projects at Kainos are intra-organizational, involving the transfer of responsibility for systems developed by a Kainos team to its Service Support Department. In some cases, client contracts allow for one or more years of maintenance support on top of initial development. More commonly, however, the company has to win a competitive tendering process to obtain such work.

The remaining 25 % of projects at Kainos are inter-organizational, either in receiving systems developed in other organizations or in passing on systems that it has created. Such arrangements often reflect the preferences of individual clients. For example, some organizations, such as the UK Government, generally develop in-house and then contract out support responsibility for the resulting systems. Similarly, there are organizations that commission the initial development of systems with the intention of taking responsibility for them after deployment.

When competing for projects, Kainos transition arrangements are made explicit, as part of the contract. These are defined around its ITIL-based support service. In particular, this involves the creation of a Support Handover document for each transition. The document is instantiated from a general template that identifies all of the information that has to be provided by the client. This ranges from basic contact details, through descriptions of the software and associated tools, to a summary of known issues. Checklists are used to ensure that no relevant information is overlooked.

The many activities associated with transition in Kainos fall into three areas:

Software transition is largely independent of agile practice, though with agile projects less documentation is expected and a more comprehensive test suite is likely to be in place.

Process transition is generally straightforward regardless of the practices on either side of the transition. Generally, the maintenance organization adapts to client requirements, though small adjustments on the client side may be necessary. For example, clients accustomed to reporting issues at the end of a sprint cycle, will need to report them immediately in the maintenance phase.

It is important for clients to be aware of the difficulty of knowledge transfer and allow for it in their planning and costing of maintenance support. The options available are discussed in the next sub-section.

One major factor influencing the efficiency and effectiveness of transition is the degree of overlap between development and maintenance. With self-to-self and intra-organizational transitions, both occurring within Kainos, there is flexibility in when and how transition is handled. For inter-organizational transitions, however, the process has to be treated formally. There are three situations to consider. The first is where there is no significant overlap between development and maintenance, implying an immediate transfer of system responsibly from one team to another. In such cases, knowledge transition is more difficult, because typically there is little to no communication between the two teams involved, except through documentation. This is more of a problem for agile development projects where less documentation is produced.

Where there is an overlap in transition between development and maintenance, there are two options available:

Maintainer-site transition has the advantage of occurring at a less pressured time, after deployment, but is typically less satisfactory overall. In particular, development team members have a weaker role, as they are not driving the transition; also, they are unlikely to be senior members of the team and so may lack a full understanding of all aspects of the system and its support.

Developer-site transition can be a pressured situation if performed around a ‘go live’ date, which is often the case. A cyclical agile development structure is very helpful here, however, in that it allows the maintenance staff to join a project at the beginning of a sprint, and so be directly involved in its planning and subsequent review. Therefore, while developer-site transition is preferable to having no transition overlap at all, embedding maintenance staff in the development team appears to be the better option. This is the approach described in the next section in a project for the UK Government Cabinet Office.

The system, IER (Individual Electoral Registration), provides a single hub through which those eligible to vote in England, Scotland and Wales can register online. This covers 46 million people, across 387 local authorities. The service went live on 10 June 2014. The maintenance contract was awarded to Kainos in the same month, with the transition to maintenance occurring across July and August 2014. Thirty days of Kainos staff time were agreed to support the transition process. Two senior Kainos support engineers (normally based in Belfast) travelled separately to the developer site (in London) for part of each week; one engineer focused on web operations and the other on the remainder of the application (the first named author of this paper). The transition occurred after the ‘go live’ date, so developers were less pressured, although it did mean that fewer of them were available for consultation.

A full schedule of activity was developed and approved ahead of the on-site transition, indicating the work to be completed each day by each Kainos engineer. As part of their transition schedule, the Kainos engineers worked alongside their counterparts in GDS, assisting with the sprint backlog and working through incidents that occurred.

The main lessons learned from the Cabinet Office transition project were: