Outsourcing response-ability: The agile transformation of the Danish public sector

This study sets out to understand the governance consequences of the ’agile transformation’ of the Danish state. The agile transformation builds on a set of values and routines from software engineering that advocates for change in the project management of digital public service provision. An ‘agile’ public sector promises to deliver not just more thoroughly digitalized public services, but also better digitalization by enhancing the speed, flexibility and innovative capabilities of IT project management in the public sector agencies tasked with building new IT systems. However, such an agile transformation is not easily accomplished, and its implications for the welfare state remain unclear. In this chapter, we problematize the Danish state’s attempted agile transformation from four perspectives: governance, sourcing, citizenship, and legacy and maintenance.

From a governance perspective, the high velocity of day-to-day decisions built into the agile framework can lead to a decoupling between decision-making and accountability in public service delivery. But when agile approaches replace bureaucratic procedures originally put in place to ensure the accountability and legality of governmental operations, what are the consequences? Further, as the distribution of knowledge between the state and private consultancies has become increasingly interlaced through agile-based public-private collaborations, the state has attempted a shift from outsourcing to insourcing (‘hjemtagning’) of IT development. At the same time, the state’s collaboration with private actors has perhaps never been more intense, and it remains unclear how the much-needed IT expertise of the private sector interplays with the state’s growing ambitions of building new systems in-house.

As regards citizenship and citizens’ trust in the state, the trial-and-error-based agile approach to service delivery may put a strain on the relationship between citizens and the welfare state by introducing “unfinished” minimal viable products (MVP) in the place of the fully operational IT systems citizens have learned to expect. Moreover, agile-based public services are often built upon an established base of legacy technology, which also impacts agile temporalities. Maintenance of pre-agile components cannot be easily contained in a sprint-based formula. And what happens after agile-based public services go beyond beta, or even face retirement? Does the responsibility for forming the strategy for the entire life-span of a product lie with the state or the vendor, and how can this responsibility be shared?