ArticlePDF Available

Agile innovation management in government: A research agenda


Abstract and Figures

Governments are facing an information technology upgrade and legacy problem: outdated systems and acquisition processes are resulting in high-risk technology projects that are either over budget or behind schedule. Recent catastrophic technology failures, such as the failed launch of the politically contested online marketplace in the U.S. were attributed to an overreliance on external technology contractors and failures to manage large-scale technology contracts in government. As a response, agile software development and modular acquisition approaches, new independent organizational units equipped with fast reacting teams, in combination with a series of policy changes are developed to address the need to innovate digital service delivery in government. This article uses a process tracing approach, as well as initial qualitative interviews with a subset of executives and agency-level digital services members to provide an overview of the existing policies and implementation approaches toward an agile innovation management approach. The article then provides a research framework including research questions that provide guidance for future research on the managerial implementation considerations necessary to scale up the initial efforts and move toward a collaborative and agile innovation management approach in government.
Content may be subject to copyright.
Agile innovation management in government: A research agenda
Ines Mergel Dr.
University of Konstanz, Germany
abstractarticle info
Article history:
Received 16 July 2016
Received in revised form 19 July 2016
Accepted 19 July 2016
Available online xxxx
Governments are facing an information technology upgrade and legacy problem: outdated systems and acquisi-
tion processes are resulting in high-risk technology projects that are either over budget or behind schedule. Re-
cent catastrophic technology failures, such as the failed launch of the politically contested online marketplace in the U.S. were attributed to an overreliance on external technology contractors and failures to
manage large-scale technology contracts in government. As a response,agile software development and modular
acquisition approaches, new independentorganizational units equippedwith fast reactingteams, in combination
with a series of policy changes are developed to address the need to innovate digital service delivery in govern-
ment. This article uses a process tracing approach, as well as initial qualitative interviews with a subset of exec-
utives and agency-level digital services members to provide an overview of the existing policies and
implementation approaches toward an agile innovation management approach. The article then provides a re-
search framework including research questions that provide guidance for future research on the managerialim-
plementation considerations necessary to scale up the initial efforts and move toward a collaborative and agile
innovation management approach in government.
© 2016 Published by Elsevier Inc.
Agile government
Agile development
Digital service delivery
1. Introduction
Previous waves of digital innovation managementwere closely con-
nected to fads and fashions in public management. The New Public
Management era for example brought about disaggregation, competi-
tion, and incentives to outsource digital service delivery and reduced
skills and capacities in government (Dunleavy, Margetts, Bastow, &
Tinkler, 2005). The result is that contract managers in government are
oftentimes following a performance-based acquisition process that
aims to anticipate the nal software products within a rigid framework
of contract fulllment obligations. These IT acquisition norms led to in-
creased complexities, delays or even failed delivery of digital services
(Anthopoulos, Reddick, Giannakidou, & Mavridis, 2016): as an example
the U.S. virtual marketplace to sell mandatory health in-
surance coverage to citizens failed to launch and had to be rescued by a
team of Google engineers in an emergency turn-around that costseveral
100 million dollars over the initially contracted price. As a result, practi-
tioners and researchers are now calling for adaptive (Janssen & van der
Voort, 2016), anticipatory (Bertot, Estevez, & Janowski, 2016), and agile
(Balter, 2011; Margetts & Dunleavy, 2013) approaches to reintegrate
digital service delivery with a holistic focus on human- and client-cen-
tered design delivered through shorter development cycles.
Agile innovation management is introduced here as an umbrella
term that describes a set of project management and software
development processes, adjusted procurement procedures, combined
with HR policies, and organizational and managerial approaches to sup-
port innovative digital service delivery in government. Innovation in
government software development are created by using an agile soft-
ware development approach adopted fromprivate sector and especially
IT sector organizationsthat are involved in creating software projects on
a shortened project management life cycle. In comparison to the tradi-
tional waterfall project management approach in which each phase se-
quentially follows the previous phase, an agile approach focuses on
shorter development phases and radical collaboration with the client
in each phase. Subprojects and results are presented and tested imme-
diately and not delayed until the nal product is presented at the end
of the fully completed contract. The method evolved as part of a new
product managementapproach in Japan and was subsequently
adopted by the IT industry (Takeuchi & Nonaka, 1986).
Recent developments have shown that government agencies are
implementing similar approaches in order to update large-scale legacy
system and adapt to environmental changes and citizen requests faster.
Driven by negative experiences, the overrelianceon external IT contrac-
tors, and management oversight failures, the current administration
took the introduction of as a stepping stone to introduce
agile development processes. In 2013, was initiated by a
top-down Presidential mandate to create an online marketplace that
brings together insurance providers offering health insurance to indi-
vidual citizens based on the income, family status, and location of
their residence by state. The implementation was a massive IT failure
that included over 50 subcontractors and IT spending of over $800
Government Information Quarterly xxx (2016) xxxxxx
E-mail address:
GOVINF-01185; No. of pages: 8; 4C:
0740-624X/© 2016 Published by Elsevier Inc.
Contents lists available at ScienceDirect
Government Information Quarterly
journal homepage:
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
million (see for example Christy, 2016). The contractors and those re-
sponsible at the Department of Health and Human Services never con-
ducted test runs with a subset of user groups, instead the decision was
to go live on the day of the reveal of the platform. For the administration
this was the rst time they saw the platform running after months of
development. Similarly other high-risk IT projects fail in government:
94% of IT projects in theU.S. federal government are over budget and be-
hind schedule and 40% are never nished (Torgovnick, 2016).
The traditional waterfall software development methods in the cur-
rent acquisition paradigm of government contracting is highly
intransparent and dissatisfying both for government clients who do not
receive the expected products, as well as for contractors who are tied to
the existing acquisition and contracting rules to deliver what is dened
in incomplete IT contracts. As Read (2016) in a recent TechInsider post
said: Government workers tend not to invite the customers to see the sau-
sage being made, but wait until the silver platter is ready.
The data collected for this study were informed by an initial litera-
ture review of mostly the computer science literature to derive the
core concept of agile software development and to contrast it to tradi-
tional development methods. This distinction drawn in the literature
as well as in government policies, guidance documents, and reports
were then used to inform a semi-structured interview outline for gov-
ernment ofcials in the U.S. federal government (Drever, 1995). The in-
terview partners included eight top managers of the central digital
transformation team located in the General Services Administration
(GSA) responsible for replicating practices across the federal govern-
ment and representatives of ve different federal departments in the
U.S. government which have already started to apply agile innovation
management approaches. The selection includes one case only the
U.S. federal government mainly because the case is well-documented
by government technology media articles, but also because each agency
faces similar contextual opportunities and constraints (Strauss & Corbin,
1998). Other governments, such as the United Kingdom or the Nether-
lands have gained similar experiences and more research is needed to
understand each case in depth. The interviews, document search and
tracing, as well as the existing literature were then used to draw initial
conclusions about the concept of agile innovation management.
This article rst reviews the development of agile approaches, the
underlying principles, the components of an agile development process
in contrast to a traditional waterfall project management approach pre-
ferred by IT contractors, and then highlights the benets and challenges
of agile development in government. The article then presents insights
from a processtracing approach (Collier, 2011) and initial qua litative in-
terviews and presents a two-layered research framework using agile
principles for the implementation of agile innovation management
based on the insights of the U.S. federal government case. Agile innova-
tion management is presented here as a comprehensive framework that
highlights how agile methods also need policy and management chang-
es in order to contribute to government innovations. Finally, the article
ends with a set of open research questions that need empirical evidence
to understand the concept of agile government, acquisition processes,
cultural changes, as well as HR and training needs.
2. Agile development process: from sequential to overlapping soft-
ware development
The development, management, and operation of IT projects in gov-
ernment traditionally follow a waterfall approach: tackling one piece of
the development phase at a time and providing the nal product to the
buyer. This is largely attributed to the current acquisition procedures
and contracting practices. Recently, more and more agile development
approaches that are well-established in the private sector have been
moved into government operations, challenging project management,
acquisition rules and standards, as well as the culture of project teams
and contract managers. In the following, a brief overview of these two
different approaches is provided.
2.1. Traditional software development process: sequential, waterfall soft-
ware development
Most IT contracts and internal modes of software development in
the public sector use a sequential process, in which one phase has to
be completed before the team is allowed to progress to the next
phase. This progression ows from top to bottom, like a cascading wa-
terfalland is therefore called the waterfall development method
(Royce, 1970). The core belief here is that by nishing each phase and
eliminating any possible mistakes for this phase, future phases won't
be impacted by mistakes and the project team won't lose time and
money by going back to x the mistakes.
The downside is that contract managers and developers must have a
fully developed plan before they write a request for proposals, sign a
contract, and start work on the nal product. The reality in government
is however, that IT professionals and contract managers don't have all
the nal details available to dene and specify the details of a contract.
This circumstance oftentimes leads to contract add-ons or extensions to
accommodate for changing internal needs or to ll in the gaps that exist
at the beginning of the request for proposals phase.
Given the xed structure of IT contracts in government, risk-aver-
sion to veer outside the contractual obligations and oftentimes unfore-
seen adjustments, government organizations tend to follow initial
rigid contractual structure (Balter, 2011). Project phases are predened
with deadlines and deliverables that are tied to payments and leave lit-
tle room for uid adjustments that might be necessary to t in initial
omissions or client changes along the development process. As a result,
waterfall methods are criticized for their rigidity, inexibility, and lack
of communication with the clients and users during the development
process. They tend to ll the contract requirements and support risk-
averse approaches of government contract managers, but mightnot sat-
isfy the users, clients, or government employees who have to use the
nal product to support the mission of their organization (GAO,
2012). At the end, waterfall methods are not able to respond to changes
in the environment that are destined to happen, especially in large-
scale, long-term delivery contracts. As a result, expensive follow-up ser-
vice contracts have to be signed to manage required changes and re-
spond to the actual user requirements. A waterfall process shown in
the following gure therefore favors thenal product and contract com-
pliance over users' needs and actual use of the nal product (Fig. 1):
A major disadvantage of a waterfall development approach is that
while the project team works through each phase, it can never respond
to changingneeds and requirements and never knows the true progress
or nal outcomes. Only at the end atwhat are usually mega launches
the software might fail and problems are not known until the end. The
customer or contract owner is only invited to get involved in testing
the nal product at the end of the development process. Evaluations
of the project status do not occur until the very end.
2.2. The alternative: agile, overlapping development
While the step-wise process initially made sense, Royce (1970) stat-
ed already in 1970 that it is risky and invites failure. He continues to
Fig. 1. Waterfall development process.
2I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
explain: The testing phase whichoccurs at the end of the development
cycle is the rst event for which timing, storage, input/output transfers,
etc., are experienced as distinguished from analyzed.(Royce
1970:329). The reality in government is that there are continuously
changing developments and developers cannot assume that agencies,
especially non-IT contract managers, are able to adequately predict
the specications of large-scale IT projects. This is animmense challenge
for the acquisition process and the way vendors and contractors who
win a bid are then tied to the process and predened outcomes.
In contrast to waterfall development methods, agile development is
a method that involves creating, testing, and improving technology
products incrementally, instead of waiting for the foolproof delivery
by the end of the contract period in a traditional IT contracting agree-
ment. Agile methods were rst introduced outside the IT industry, but
are mostly known for its advances in software development: the phys-
icist and statistician Walter Shewhart of Bell Labs began applying Plan-
Do-Study-Act (PDSA) cycles to the improvement of products and pro-
cesses (Goldman & Preiss, 1994). His approach constitutes the rst iter-
ative and incremental development approach to rapidly respond to
changes and actual ndings in the development process.
In 1986, Takeuchi and Nonaka introduced a team-oriented approach
to bring products to market faster and called it the rugbyapproach
where a team tries to go the whole distance as a unit, passing the ball
back and forth(Rigby, Sutherland, & Takeuchi, 2016b;Takeuchi &
Nonaka, 1986). They started to consider large software development
projects as multiple independent tasks. Takeuchi and Nonaka (1986)
called their iterative and incremental agile software development
framework the scrum method: small, self-organizing, adaptive teams
that are tasked with solving complex problems using overlapping de-
velopment phases. The tasks are broken down into small, manageable
modules and use the short development cycles, hold brief daily
stand-upmeetings to review progress and identify roadblocks that
might prevent them from moving forward. In addition, progress is visu-
alized in a process management system called Kanban, that helps teams
to reduce lead times and the amount of work in process. In the mean-
time, these principles are also included in the agile development mani-
festo (Agile Manifesto, 2001).
The starting point for an agile developmentprocessis qualitative re-
search conducted by the project team to understand what the needs of
the clients are. Clients in government canbe agencies and contract man-
agers themselves, or external clients, such as partners or citizens who
will use the nal product. These user stories are collected using the lan-
guage of the clients to avoid misconception or translation mistakes with
the hope that using language that is known and familiar to the client
will ultimately make it easier for them to use the nal product and easily
integrate it into their day-to-day use. An important principle ofagile de-
velopment processes is to be able to react to changes that are initiated to
the changing requirements from clients, or as Cockburn (2002, 10) puts
it, it is a declaration of prioritizing for project management vulnerabil-
ity with respect to shifting requirements, shifting technology, and a
shifting understanding the situation.
The agile development method follows so-called sprint cyclesso
that the development teams by design fail often and early, instead of
failing catastrophically and wasting taxpayer money as seen with the
U.S. online marketplace for sale of health insurances,
The iterations or sprints are following the traditional waterfall in
each segment, but usually take between 1 and 8 weeks for each seg-
ment, and projects lasts no longer than six months. Similar to project
teams in the IT industry, this approach follows the motto: fail fast,
early, and oftenwith small prototypes that rapidly prove (or disprove)
an idea before much is invested (Leetaru, 2016). The initial plan serves
as guidance, but the plans are revised after each iteration and the devel-
opment output is demonstrated to the client and other stakeholders.
This early evaluation phase reveals which requirements may not have
been fully addressed and can be added as a work package for the next
sprint. One important characteristic of an agile approach is therefore
radical collaboration: clients are working closely with IT engineers and
Another important characteristic of an agile approach is continuous
delivery of output to the clients (Agile Manifesto, 2001;Martin, 2003):
the uid involvement of the client in the development process allows
for continuous feedback and improvement in all stages of the process.
This requires an increased time commitment by the client be it a gov-
ernment agency's representatives or the citizens. These agile character-
istics shift practices and values: the value is not generated by delivering
anal product that fullls the initial RFP or contract. Instead, value is
created by putting the client at the center of the project and delivering
anal product that benets the client and creates value for the public.
Similar modular software development approaches include rapid or spi-
ral development as alternatives to waterfall methods. Here as dened
by the case selected I focus on agile approaches only.
The following gure shows the iterative sprint cycles as part of the
overall development process (Fig. 2):
Rigby, Sutherland, and Takeuchi (2016a) note that agile methods
can be best applied in contexts with complex problems when the nal
solution might not be predictable or is initially unknown to both clients
and developers especially environments like government. They also
note, that agile methods need training and potentially behavioral
change, not just in the use of new technologies and approaches, but
also in terms of attitudes toward contracting and involvement of clients
and developers in project teams (Agile Manifesto, 2001).
Using an agile approach supports more adaptive governance ap-
proaches as promoted by Janssen and van der Voort (2016): instead of
predicting and prescribing the outcomes, an adaptive government can
use agile methods to increase its exibility in responding to changes
and might in the process even deliver less costly innovations in govern-
ment. However only using agile software development approaches is
not enough to fundamentally change how government can tackle the
update and legacy problems it faces. Instead, a multi-layered approach
is needed that goes beyond the development approach. In the following,
based on the case of the U.S. federal government a comprehensive agile
innovation management approach is outlined.
3. Implementing agile innovation managementpractices: the case of
the U.S. federal government
Tracing the process of agile innovation management in the U.S. federal
government is relatively difcult, because there is no ofcial mandate for
a comprehensive strategy at this point. Individual agencies are making
progress using initial guidance from the Ofce of Management and Bud-
get (OMB) to adapt their IT acquisition practices or collaborate with the
General Service Administration's technology transformation service
to get advice on how to use agile methods. Agencies were asked to
submit condential budgets that are not publicly available to outline the
need for resources to invest in agile innovation management practices.
In the following, Collier's (2011) approach is used to trace the process
through which government documents has encouraged agencies to ex-
periment with agile methodologies and improve their acquisition prac-
tices. The goal is to make causal observations by combing document
reviews with empirical evidence from initial qualitative interviews.
A recent GAO report (2015) has criticized the existing standard op-
erating procedures for IT acquisition: Federal investments in informa-
tion technology (IT) have often resulted in multimillion dollar cost
overrunsand years-long schedule delays, with questionable mission-re-
lated achievements.A case in point is the implementa-
tion disaster. GAO (2014) has attributed the failure of the IT platform to
The agency name 18F is derived from its location at 18th and F Street in Washington,
3I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
mistakes in contract planning and lack of oversight practices among the
responsible Department of Health and Human Service's IT staff.
The Ofce of Management and Budget (OMB) has instructed federal
departments and agencies to usepart of their IT budgetto set up digital
service teams modeled after the U.S. Digital Service team a quick re-
sponse team located in the White House that helped with the recovery
of shift in moving resources toward improving cus-
tomer-centric service delivery follows the 2011 Executive Order 13571
(The White House, 2011) and OBM's implementation instructions
(Ofce of Management and Budget, 2011), the 2012 White House' Dig-
ital Strategy (The White House, 2012b), and the Presidential Memoran-
dum instructing the federal government to work towardBuilding a 21st
Century Digital Government(The White House, 2012c).
In 2014, the WhiteHouse established the U.S. Digital Services team
a quick response team of IT engineers recruited from the private sector
to help with Presidential priority IT projects - and the General Services
Administration's 18F software development teams. Engineers are re-
cruited from technology companies, including Facebook, Twitter, Goo-
gle, Microsoft, or Amazon. The so-called digital swat teamsof USDS
and 18F are paired with public servants using agile software develop-
ment methods to collaboratively work on high-priority projects, such
as the digitization of the U.S. immigration service forms which are still
mostly paper-based, or the Department of Veterans' Affairs' education
and health service delivery processes.
In addition, the introduction of the Presidential Innovation Fellow pro-
gram (The White House, 2015) - an HR instrument that allows Tour of
Dutyappointments - are creating opportunities to move external talent
from the private sector into government for short periods of time to con-
duct specic tasks and then return to their previous positions.
Similar to the UK and soon the Italian government (,
2016;, 2016), the U.S. federal government as explicitly adopted
an agile government approach in 2012 (The White House, 2012b,
2011). The Obama budget 2016 includes $106 million to scale and in-
stitutionalizethe still-new U.S. Digital Service by creating similar agen-
cy-level digital teams within the largest 25 federal agencies. In some
pockets of the U.S. federal government, especially in defense and intel-
ligence agencies, agile methods have been tried and proven to be effec-
tive ways to improve software development processes. For example, the
U.S. Army has created simulation programs using both agile and tradi-
tional methods (Surdu & Parsons, 2006). The Federal Bureau of Investi-
gation (FBI) has worked with its contractor Lockheed Martin on the
Sentinel project to create a case management software to change how
the Bureau gathers, stores, and links data (Fulgham, Johnson, Crandall,
Jackson, & Burrows, 2011). Especially the upfront denition of require-
ments as part of the standard development process is considered as in-
efcient and ineffective and oftentimes takes years (The White House,
2012a), so that the project team evaluated the existing software devel-
opment methodologies and moved to sprint cycles including outside
stakeholders in the process and more effectively managed risks, costs,
and outcomes. Small teams of a manageable size (up to 15 team mem-
bers) are set up to create collaborations between FBI employees and
government contractors. These teams are using iterative development
within the scrum project management framework: iterative develop-
ment sprints, each sprint involves the completion of a small set of
tasks in two week cycles, reducing the risk of large scale failure.
At the Department of Defense, the term agile is used as an umbrella
term for many different iterative development processes, including
Scrum, Lean Development, or extreme programming (XP) (Broadus,
2013). Agile methods are included into contract documents as detailed
in the 2010 Defense Acquisition Bill (2010) (Sutherland, 2012), howev-
er DoD ofcials experienced that for example technical documentations
were missing at critical design reviews and therefore recommends to
invest more in training contract managers and contractors in agile prac-
tices (Lapham, 2012). In a recent speech, the Secretary of Defense Carter
highlighted the urgency to become more agile as a whole enterprise:
DOD doesn't have many effective ways to harness promising technolo-
gies they come up with. We need to x that. I don't want us to lose out
on an innovative idea or capability we need because the Pentagon bu-
reaucracy was too slow to fund something, or we weren't amenable to
working with as many startups as we could be.(U.S. DoD, 2015).
In addition to these rst experiments, 18F has identied the need for
an increased knowledge and expertise among their federal clients to
change the government's IT acquisition practices. They are working to-
ward improving acquisition and contract ofcers ability to know what
to do and questions to ask at their next acquisition negation with con-
tractors (Christy, 2016). Contractors have to agree the open source ap-
proaches, so that source code can be reused across the government.
4. Building blocks of an agile innovation management approach
The agile innovation management framework as observed in the U.S.
federal government can be divided into two layers: the rst layer or
the basis of the framework includes foundational policies that need to
be adapted in order to shift once learned behavior and practices toward
an agile practice. The second layer is the management layer that includes
management activities focused on innovative processes, and leadership
activities focused on providing cover for all the management activities.
4.1. Base layer: policies
The base layer includes innovative HR policies.In the case of the U.S.
federal government only one major HR policy change was introduced
Fig. 2. Agile sprint cycles.
4I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
during the eight-year presidency of President Obama. He created a new
program that is called the Preside ntial Innovation Fellows Progra m (The
White House, 2015). Under the umbrella of this program, IT talents
were recruited skilled in technology or innovative practices to serve
in the Federal Government to work on some of the Nation's biggest
and most pressing challenges.Among the recruits the Executive
Order specied thatexecutives, innovators, or successful entrepreneurs
were asked to conduct a so-called Tour of Dutyand spend short term
stay in the federal government in order to create meaningful solutions
that can help save lives and taxpayer money, fuel job creation, and sig-
nicantly improve how the Federal Government serves the American
people.These time-limited appointments are meant as an incentive
to briey serve the country and especially infuse the federal govern-
ment with skills and practices from the private sector. In practice, sever-
al of the PIFs (Presidential Innovation Fellows) extend their stays to
nish their projects beyond the initial six months' time period or even
moved into permanent positions in government.
The second type of policies focuses on updated acquisition policies
that allow agencies to use agile methodologies when they write Request
for proposals from vendors. As Mark Schwartz, Chief Information Ofcer
of the U.S. Citizenship and Immigration Services publicly stated, it is im-
portant for the government to Buy competent teams, rather than buying
a product.(Read, 2016). Using Agile BPAs (Blanket Purchase Agree-
ments), vendors, who were already preapproved on the agencies sched-
ules, have to showcase prototypes of their nal products and agree to
deliver their products using agile methodologies with sprint cycles.
Agile BPAs were introduced using the Ofce of Management and Budget's
Modular Contracting Guidance (GAO, 2012;The White House, 2012a).
Under this framework the expectation is that government agencies invest
in smaller projects and increments and open opportunities for small busi-
nesses to compete for government contracts. This will reduce the risk ex-
posure and avoid sunk costs of grand designprojects.
4.2. Management layer: process management and leadership
The management layer of the agile innovation management frame-
work includes process management and agile leadership as the um-
brella to facilitate all other activities in the framework.
First, theprocess layer includes a strict application of agile methodol-
ogies. An important rst step is research. The client's real underlying
needs are researched using qualitative exploration methods with
focus groups, end-users, and agency staff to understand what products
or processes are actually needed. This user- or human-centered design
approach steps away from contract management requirements and
pushes the end-users of the projects into the focus. They dene what
products they need and which processes they will actually use. As
Robert Read (2016), 18F co-founder and 18F consulting founder sug-
gests, agile teams need to ask only open-ended questions rather than
metric survey questions. The research team uses A/B testing, surveys
of at most nine users, and in-person interviews. After that a prototype
is quickly built and as part of the rst sprint cycle, developers and agen-
cy partners improve the product iteratively and then test publicly in a
so-called moment-of-truthphase. Lastly, the fully developed product
becomes operational for all end users.
18F teams up with other agencies using their ve business lines: 1)
develop and build custom products for agencies, 2) develop innovative
ways to buy technology, 3) provide platforms that departments and
agencies can use, 4) consulting services to agencies to implement their
own digital services teams, and 5) provide training in modern digital
services techniques. One support function is to provide contract writing
support. This so-called RFP ghost-writingadvice helps agency-level
contract managers understand how to include agile methods into RFPs
and how to identify suitable vendors and contracts. In case agencies de-
cide to use 18F's services to build new software, inter-agency agree-
ments are signed on a fee-for-service basis.
At the top of the management layer, agile government leadership is
necessary to provide so-called air coverfor all activities from the
top. Beyond strategic planning activities, leadership is responsible for
the integration of the digital services teams, software developers, and
agency-level staff. The expectation is to create hyper transparency in
order to promote values and processes, support policies, provide sup-
port for teams to experiment with new methods, or outreach. Moreover,
leadership is necessary to protect the team culture and provide incen-
tives for external IT talents. The following gure summarizes the policy
and management layer of the agile innovation management framework
(Fig. 3):
Fig. 3. Agile innovation management building blocks.
5I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
5. Discussion and future research
Building on previous approaches, such as Janssen and van der
Voort's (2016) suggestions for an adaptive government, agile innova-
tion management can be considered as a value framework for the over-
all enterprise of government. It goes beyond the project- or process-
based viewpoint and therefore needs to evolve around a set of princi-
ples that not only focus on the software development process.
An agile innovation management framework needs to consider ase-
ries of agile innovation principles that have the potential to change how
government acquires or creates IT innovation itself. The main principle
is open by default: software is developed and delivered once either
with the help of contractors who agree to use agile development
methods or built inhouse. The source code is then shared on social cod-
ing sites suchas Github so that other government agencies don't need to
replicate the efforts and a continuous improvement process contributes
to the de-siloing of government (Dunleavy & Margetts, 2015;Mergel,
The second principle is the need for an agile leadership approach.
While scholars and practitioners might be dismissing the importance
of leadership and management in the design implementation of innova-
tion, in risk-averse government environments no action is taken with-
out explicit top-down conrmation. An agile leadership approach
(Ryan & Ali, 2016) helps to change deep seated attitudes, values, and
habits of the hierarchical bureaucracy. Leadership workstoward cultur-
al changes that allow for open collaboration between contractors and
internal development teams and changes the perception that the only
safe approach to deliver is a complete plan. Agile leaders are responsible
for guiding a team to success even in situations where they are inexpe-
rienced in agile methods and introduces the culture of prototyping and
experimentation using shortened timelines that help to deliver results
faster. They also incorporate the possibilities to explore alternatives
and allow their teams to fail. The difference to risk-averse failing ap-
proachesis that failure in anexperimental design approach occursfaster
and errors can be eliminated faster not a yearor two into the contract
delivery timeline. This procedural innovation creates a cultural change
from contract management to participatory and collaborative culture.
Agile leaders also have the ability to create an environment and the sup-
port for motivated contributors to trust the process and motivate them
to participate (Fowler & Highsmith, 2001).
The third design principle includes alternative contracting and
outsourcing approaches (GAO, 2013;USDS, 2015, 2016). Governments
are in the habit of big designs up-front.This is especially true in the
U.S. federal government that is driven by budget incentives as well as
existing rules and regulations. Firm xed-price contracts are considered
as the common contract type. Full specications have to be agreed upon
upfront, even though most contract managers have little knowledge of
IT specications and actual users of the output are not included in the
early design and specication phases. Contractors then need to deliver
on the once agreed contract or suggest follow-up contracts. The benets
of a comprehensive agile innovation management approach is that cli-
ents, end users, contract managers, and contractors are included in the
contract specication phase and leave enough room for adjustments
as they go through the implementation and delivery phases. With con-
tinuous iterations, small failures are quickly corrected and will lead to
successful outcomes earlier (Dullemond, van Gameren, & van
Solingen, 2009). The result is that government can create teams of intra-
preneurs or entrepreneurs (Schumpeter, 1949) who see government as
a start-up opportunity by stepping away from the standard operating
procedures of IT innovation and acquisition.
6. Future research on agile innovation management in government
Current research on agile innovation management in government is
lacking in the information management literature. Most research that is
contributed resides in the computer science eld and focuses on scrum
and agile methodologies, however there is limited research that pays at-
tention to the actual implementation challenges, innovative outcomes,
or transformation of digital services in government. The following
open research questions might help readers focus their own efforts to
contribute to the discipline and gain an understanding how govern-
ments can overcome their IT legacy problems, move away from stale
and risk-averse acquisition routinesthat might lead to delays in delivery
and push contractors to deliver over budget.
Innovative agile acquisition practices: innovative acquisition practices
are a learning experience for both IT contractmanagers in government
as well as IT industry contractors. A recent congressional hearing
allowed lobbyist from the software development industry to state
their concerns, that some contractors might be left behind who are
not willing to offer agile methodologies or who are not willing to reveal
their source code for proprietary reasons (Committee on Oversight &
Government Reform, 2016). It is unclear at this point to what degree
the contracting industry is impacted by changing requirements of gov-
ernment. Additional research is needed to understand a) how agile
methodologies are changing the landscape of the IT software industry
and specically vendors who have not offered agile methodologies so
far, and b) do these agile blanket purchasing agreements lead to cost
savings, more effective and efcient IT contracting practices, and are
they truly contributing to increased user- and client-centric outcomes?
The principle open by defaultties into the acquisition procedures
that force contractors to make their code open source, as well as the
sharing of software code (Crowston, Wei, Howison, & Wiggins, 2012).
Currently, in the U.S. case, the principles are followed, however there
is no ofcial policy. A draft policy document is circulating with the re-
quest for comments and the intention of the White House was publicly
stated (Scott, 2016). So far there is little empirical evidence how open
source development can lead to sharing of resources or the reduction
of double work in government. Just because the source code is open
does not necessarily mean that agencies also see the value in it
(Raymonds, 1999). Does sharing of software code as seen for example
on Github (Mergel, 2015) truly lead to increased collaboration among
agencies contributing to the improvement of each others' code, to the
actual reuse of already existing code, and subsequently to reduced
spending of tax payer money? In addition, do existing open source pol-
icies lead to the expected change in acquisition procedures? Recently,
the U.S. federal government even unpublished its source code for the
problematic website (Jeffreis, 2013). Do vendors and
governments - comply with the policies? As an example, a recent Con-
gressional Hearing of the Oversight Committee in the U.S. has shown
that the software industry is against open source development
(Committee on Oversight & Government Reform, 2016). How can gov-
ernment incentivize open sharing of source code instead of reinventing
the wheel with every request for proposals, signed contract or grant?
Some insights might be gleaned from other types of sharing services
outside the software development problem.
Another important effort focuses on scaling up practices and replicat-
ing lessons learned from the digital swat teams in the White House
across the U.S. federal government. As Boehm and Turner (2005:30)
point out: on small, stand-alone projects agile practices are less bur-
densome and more in tune with the software industry's increasing
need for rapid development and coping with continuous change,how-
ever, they also observe the difculty scaling up and integrating them
into traditional, top-down systems. Especially in government, where
organizations are expending 80% of their budget on maintaining legacy
systems, it is unclear how agile innovation management practices can
be scaled up from the project level to transforming overall digital ap-
proaches for each agency and government as a whole. It is important
to understand how open by default practices can be adopted and imple-
mented in the current environment that is still extremely risk averse.
While there is evidence that projects that adhere to agile development
concepts were nearly twice as likely to deliver on time than those that
used the traditional waterfalldevelopment technique, it is still a
6I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
show-and-tell effort to convince agency leadership and especially IT
contracting managers to buy into the concepts. Future research can
focus on diffusion of agile practices, but also on comparative studies to
highlight the differences between a traditional contracting approach
and an agile innovation management approach.
The main challenge for government is the cultural change that needs
to go hand-in-hand with the procedural changes. The current notion of
small vs. big governmenthas shifted budget categories toward
contracting out and led to a reduction in IT talent that is located in gov-
ernment. Instead, contractors' and vendors' knowledge is moved from
the outside of the organization into government on a temporary basis,
but is again removed after a contract ends. How can government attract
IT talent from the private sector to serve? This is an important question
given the gap in salaries paid by the private sector and the limits to pay
out bonuses or create exible salary schemes. Once recruited,
inculturatingespecially Silicon Valley-type software engineers for
whom agile methods are the norm into a risk-averse contracting-out
environment is as Christy (2016) states a big mind shiftfor govern-
ment employees. A top-down commitment to openness and transpar-
ency by design is necessary to shift the internal paradigm, but also
many of the barriers and challenges of the current work environment
have to be adapted to allow for changes toward the start-up culture
that software engineers value in their industries. Here it is important
to understand new forms of prosocial public service motivation, that
goes beyond the intrinsic motivations to do good or contribute to the
public sector (Grant, 2007). Self-determination theories contradict the
traditional command-and-control environments in which government
bureaucracies are designed (Gagné & Deci, 2005). These theories
might go beyond the motivation to contribute to a public good as
most of the current literature on open source programmers suggests
(Blasc, Jung, & Lakhani, 2016;Budhathoki & Haythornthwaite, 2013).
It is therefore important to gain a deeper understanding how govern-
ment can attract and more importantly also retain IT talent that has
other attractive options outside the restricted environment of govern-
ment. What kind of policy and management changes are necessary to
accomplish these goals?
Agile public leadership is needed to initiate process changes from the
top, however it requires middle management support to empower and
showcase change that is possible when using an agile innovation man-
agement approach (Riby & Sutherland, 2016). Leadership is needed
when it comes to providing adequate coverage top down. This will
lighten the risk-aversion and will help managers to push through bar-
riers that have to do more with the practiced and proven approaches,
but are usually not even in the law or in any kind of other bureaucratic
norms (Ryan & Ali, 2016).It is necessary to change collaborative innova-
tion creation and sharing culture in government. As Shaikh (2016)
showed in a recent study, the adoption of open source software as the
standard approach in government is challenging: while it creates possi-
bilities of community development, sharing, and reuse in government,
there are also many barriers and clear policy changes are needed to
help government organizations to adopt an open source strategy. One
example, is the U.S. federal government's Federal Source Code draft pol-
icy document (Scott, 2016). This policy draft suggests that new soft-
ware developed specically for or by the Federal Government to be
made available for sharing and re-use across federal agencies.Howev-
er, there is little evidence so far, that leadership across the federal gov-
ernment is in support and more research is needed to understand
how top-down policies with an agile-minded leadership can provide
adequate support for broad scale change initiatives.
Lastly, Presidential initiatives are prone to disappear when an ad-
ministration transitions to its successor. National priorities might shift,
budget cuts might move temporary nancial support from one priority
to a new project, and IT talent recruited by the former administration
might return to the private sector. While there are efforts to smoothly
transition innovative initiatives from one administration to another,
projects that are not institutionalized or are seen as pet projects of a
former President might not survive the transition. Future research
needs to address how the electoral cycle and shifting national priorities
affect the adoption of agile methodologies, how commitment to innova-
tion management persists, and whether risk-taking with government
technology decisions led to sustainable changes, such as the enactment
of acquisition policies and innovative HR policies.
Overall, agile innovation management is an approach that many dif-
ferent countries are attempting with some governments in advanced
stages, others in early experimentation stage. Most of the topics listed
above are either not researched or in isolation. It is therefore important
for e-government and digital innovation researchers to conduct coun-
try-level studies, project studies, as well as human resources studies to
increase our understanding agile innovation management.
Agile Manifesto (2001). Manifesto for agile software development. (Accessed 05/10/
2016) (2016). Diego Piacentini: He will take a two-year leave to head the Italian
Prime Minister's digital technology ofce.
Anthopoulos, L., Reddick, C. G., Giannakidou, I., & Mavridis, N. (2016). Why e-government
projects fail? An analysis of the website. Government Information
Quarterly,33(1), 161173.
Balter, B. J. (2011). Toward a more agile government: The case for rebooting federal IT
procurement. Public Contract Law Journal,41(1), 151171.
Bertot, J., Estevez, E., & Janowski, T. (2016). Digital public service innovation: Framework
proposal. ICEGOV2016, Montevideo, Uruguay, March 13, 2016.
Blasc, A.,Jung, O. S., & Lakhani, K. R.(2016). Motivatingeffort in contributing to publicgoods
inside organizations: Field experimental evidence.
Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes
in traditional development organizations. IEEE Software September/October:3039.
Broadus,W. (2013). The challengesof being agile in DoD. Defense AT&L JanuaryFebruary:
Budhathoki, N. R., & Haythornthwaite,C. (2013). Motivation for open collaboration crowd
and community models and the case of OpenStree tMap. American Behavioral
Scientist,57(5), 548575.
Christy, A. (2016). Government goes agile. Stanford Social Innovation Review Spring,2016.
Cockburn, A. (2002). Learning from agile software d evelopment Part one. The Journal of
Defense Software Engineering,15(10), 1014.
Collier, D. (2011). Understanding process tracing. PS: Political Science and Politics,44(4),
Committee on Oversight and Government Reform (2016). 18F and U.S. digital services
oversight. Congressional hearing.
Crowston, K., Wei, K., Howison, J., & Wiggins, A. (2012). Free/libre open-source software
development: What we know and what we do not know. ACM Computing Surveys
(CSUR),44(2) (n.p).
Department of Defense Appropriations Act (2010). H.R.3326 111th Congress (2009).
Drever, E. (1995). Using Semi-Structured Interviews in Small-Scale Research: A Teacher's
Guide. Edinburgh: Scottish Council for Research in Education.
Dullemond, K., van Gameren, B., & van Solingen, R. (2009). How technological support
can enable advantages of agile software development in a GSE setting.Fourth IEEE In-
ternational Conference on Global Software Engineering.
Dunleavy, P., & Margetts, H. (2015). Design principles for essentially digital governance.
111th Annual Meeting of the American Political Science Association, San Francisco, 36
September 2015.
Dunleavy, P., Margetts, H., Bastow, S., & Tinkler, J. (2005). New public management is
dead - Long live digital-era governance. Journal of Public Administration Review and
Fowler, M., & Highsmith, J. (2001). The Agile Manifesto. Retrieved from http://
Fulgham, C., Johnson, J., Crandall, M., Jackson, L., & Burrows, N. (2011). The FBI gets agile.
ITProfessional,13(5), 5759.
Gagné, M., & Deci, E. L. (2005). Self-determination theory and work motivation.Journal of
Organizati onal Behavior,26(4), 331362.
GAO (2012). Software development: Effective practices and federal challenges in apply-
ing agile methods. Report to the Subcommittee on Federal Financial Management, Gov-
ernment Informa tion, Federal Serv ices, and International Security, Comm ittee on
Homeland Security and Governmental Affairs United States Senate. Washington, DC:
Government Accountability Ofce.
GAO (2013). Leveraging best practices to help ensure successful major acquisitions. In
Government Accountability Ofce (Ed.), Information technology. Washington, DC:
GAO (2014). HEALTHCARE.GOV: Contract planning and oversight practices were ineffective
given the challenges and risks.
GAO (2015). Information technology: Additional actions and oversight urgently needed
to reduce waste and improve performance in acquisitions and operation s. In
Government Accountability Ofce (Ed.), G AO-15-675T.
Goldman,S. L., & Preiss, K. (1994). Agile competitors and virtual organizations: Strategies for
enriching the customer. San Francisco, CA: Wiley.
Grant, A. M. (2007). Relational job design and the motivation to make a prosocial differ-
ence. Academy of Management Review,32(2), 393417.
7I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
Janssen, M., & van der Voort, H. (2016). Adaptive governance: Towards a stable, account-
able and responsive government. Government Information Quarterly,33(1), 15.
Jeffreis, A. 2013. "Why the government unpublished the source code for" 8/4852720/why-the-govern-
Lapham, M. A. (20 12). DoD agile adoption: Necessary considerations, concerns, and
changes. CROSSTALK - The Journal of Defense Software Engineering January/February:
Leetaru, K. (2016). System failure: What I've learned as a data scientist in Washington.
Margetts, H., & Dunleavy, P. (2013). The second wave of digital-era governance: A quasi-
paradigm for government on the web. Philosophical Transactions of the Royal Society.
Martin, R. C. (2003). Agile software development: Principles,patterns, and practices, Alan Apt
series. Upper Saddle River, NJ: Prentice Hall Pearson Education, Inc.
Mergel, I. (2015). Open collaboration in the public sector: The case of social coding on
github. Government Information Quarterly,32(4), 464472.
Ofce of Management and Budget (2011). Implementing Executive Order 13571 on
streamlining service delivery and improving customer service.
Raymonds, E. S. (1999). The Cathedral and the Bazaar: Musings on Linux and Open Source.
Sebastopol, CA: O'Reilly Media.
Read,R.L.(2016).Don't ask for permission to use agile. Just start doing it. NextGov.
Riby, D., & Sutherland, J. (2016). Understanding agile management. Harvard Business
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016a). Embracing agile. Harvard Business
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016b). The secret history of agile innovation.
Harvard Business Review.
Royce, W. (1970). Managing the development of large software systems. (IEEE WESCON).
Ryan, K., & Ali , A. (2016). The new government leader: Mobilizing agile public leadership
in disruptive times. In Deloitte University Press (Ed.), A GovLab report.
Schumpeter, J. A. (1949). Economic theory and entrepreneurial history, reprinted from
change and the entrepreneur.In R. V. (Ed.), Essays on entrepreneurs, innovations, busi-
ness cycles, and the evolution of capitalism.
Scott, T. (2016). Title.The White House: What is Happening. (03/10/2016) https://
Shaikh, M. (2016). Negotiating open source software adoption in the UK public sector.
Government Information Quarterly,33,115132.
Strauss, A., & Corbin, J. (1998). Basics of qualitative research: Techniques and procedures for
developing grounded theory. Thousand Oaks, CA: Sage Publications.
Surdu, J., & Parsons, D. J. (2006). Army simulation program balances agile and traditional
methods with success. CROSSTALK - The Journal of Defense Software Engineering April:
Sutherland, J. (2012). Title.Scrum Blog. (07/18/2012)
Takeuchi, H., & Nonaka, I. (1986). The new. New product development game. Harvard
Business Review,64(1), 137146.
The White House (2011). Executive order 13571streamlining service delivery and im-
proving customer service. Executive order 13571.
The White House. 2012a. Contracting guidance to support modular development. In Pro-
curement, edited by Ofce of Management and Budget. (Washington, DC).
The White House (2012b). Digital government: Building a 21st century platform to better
serve the American people.
The White House (2012c). Pre sidential memorandum Building a 21st century digital
The White House (2015). Executive order Presidential Innovation Fellows Program.
Torgovnick, M. K. ( 2016). What happens when you disrupt the White House: Haley Van
Dyck speaks at TED2016. Live from TED2016.
U.S. DoD (2015). Secretary of defense speech: Drell lecture: Rewiring the Pentagon: Charing
a new path on innovation and cybersecurity. (2016). Government digital service.
USDS (2015). U.S. digital services playbook. (Washington, DC.).
USDS (2016). The TechFAR handbook.
Dr. Ines Mergel is full professor of public administration at the University of Konstanz,
Germany, where she teaches classes on government innovation management. Professor
Mergel received a Doctorof Business Administration andspent six years as a postdoctoral
fellow at Harvard's Kennedy School of Government. From 2008to 2016, she taught in the
Master of Public Administration Program at Syracuse University's Maxwell School of Citi-
zenship and Public Affairs. Her research focuses on technology management innovations
mostly in the U.S. federal government.
8I. Mergel / Government Information Quarterly xxx (2016) xxxxxx
Please cite this article as: Mergel, I., Agile innovation management in government: A research agenda, Government Information Quarterly (2016),
... There are a panoply of studies that have applied these ideas specifically to the public sector (i.e. Alvarenga, Matos, Godina, & Matias, 2020;Jonathan, 2020;Kokkinakos, Markaki, Koussouris, & Psarras, 2016;Mergel, 2016). It has been reported that digital transformation makes use of digital technologies with the constant strategic renewal of an organization's business model, collaborative approach and culture (Warner & W€ ager, 2019). ...
... This is why in the era of digital change, public as well as private institutions have made lots of effort to follow suit of the many "agile" frameworks, from agile management, agile culture, to agile organizations (cf. Mergel, 2016). Today, in the digital world, strategy needs to be agile. ...
Purpose The purpose of the present paper is to show that a clearly delineated digital strategy and an agile mindset is key for the successful adoption of digital innovation in society and business. Design/methodology/approach This is a case study and critical discussion. Findings It was seen that both the business case (Netflix) and the societal case on the level of a country (El Salvador) lack a digital strategy, which initiated the innovation problems. However, Netflix proved to have an agile reactivity, which helped them to get back on track, which was not the case for El Salvador. Originality/value This discussion is relevant because the domain of “society” and the domain of “business” are often discussed as separated worlds. However, this paper intends to show that there are some logical dynamics underlying digital transformation in the case of digital innovation that apply to both of these domains.
... Core to this development is the increased utilization of digital solutions to achieve organizational change, i.e., digital transformation [2]. There have been numerous accounts of digital transformation in the public sector [3,4,5,6,7]. As highlighted by Mergel et al. [8] this also involves new cooperation modes and an increased emphasis on external utilizations of digital solutions. ...
Full-text available
Digital transformation is increasingly prioritized within the public sector to assure sustained relevance. At the same time, sustainable development goals (SDGs) are increasingly addressed in the strategies and missions of public sector actors. Previous research highlights that sustainability requires integration into internal procedures and governance structures (e.g., accounting) to avoid running the risk of merely being ceremonial and green washing. With digital transformation deemed critical for the public sector, we would hence expect to see an integration of SDGs in digital initiatives. This study answers the research question of how SDGs are integrated into digital transformation initiatives. We answer the question through purposive sampling of digital initiatives within a large, Swedish municipality, where each initiative is categorized on the notion of which SDGs they are related to. The findings show that there is a decoupling of sustainability in digital transformation initiatives, that risks leading to directly detrimental effects for both the digital transformation of the public sector as well as for sustainability. This is discussed through integration with previous literature with the intent of identifying future avenues for research and recommendations for practice.KeywordsDigital transformationSustainable development goalsSDGResponsible information systemsDigital government
... Müşterinin gerçek ihtiyaçları, hangi ürün veya süreçlerin gerçekten gerekli olduğunu anlamak için odak grupları, son kullanıcılar ve ajans personeli ile nitel keşif yöntemleri kullanılarak araştırılır. Hangi ürünlere ihtiyaç duyduklarını ve gerçekte hangi süreçleri kullanacaklarını tanımlarlar (Mergel, 2016). ...
Full-text available
Teknolojinin hızla gelişmesi sonucu birçok alanda etkileşim yaratarak yeni alanların açılmasına geleneksel işlemelerden dijital işlemlere doğru evirilmesine olanak sağlamıştır. Finans sistemi de bu dijitalleşme deviniminden payına düşeni almıştır. Finansal teknoloji terimlerinin kısaltmasından oluşan “fintek” finansal sistem içerisinde kullanılan yeni nesil teknolojileri karşılayan bir kavram olarak literatüre girmiştir. Nesnelerin interneti, bulut bilişim, kripto para, blockchain, yapay zeka gibi kavramlar fintek ekosisteminin bileşenleri haline gelmiştir. Finansal sistem içerisinde kullanımı giderek artan bu teknolojilerin Covid-19 pandemisinin etkisi ile literatürde yer alan çalışmalara ne kadar konu edildiğine ilişkin literatür taraması yapılarak mevcut durumunun fotoğrafının çekilmesine ihtiyaç olduğu düşünülmüştür. Bu çalışmada Covid-19 Pandemisi sonrası Türkiye’de Fintek alanında yapılan teorik ve ampirik çalışmaların sistematik derleme yöntemi ile incelemesi yapılmıştır. Derleme sonucunda yapılan çalışmaların, henüz fintek kavramının çerçevesinin çizilmesi ve anlaşılması üzerine olduğu, regülasyon değerlendirmelerinin olduğu ve alan özelinde kripto para, yapay zeka, açık bankacılık, blockchain gibi teknolojileri konu alan çalışmaların yapıldığı belirlenmiştir. Uluslararası düzeyde Fintek ekosistemi üzerine yapılan çalışmaların oldukça artmasına karşılık Türkiye’de fintek çalışmalarının henüz başında olduğu tüm çalışma evreni içerisinde küçük bir örneklemi oluşturduğu değerlendirilmiştir.
... Queensland Health's slow progress was, in part, a result of the government being risk-adverse to largescale technology projects and as such key stakeholders were hesitant to take ownership. This risk aversion is not unique to the Queensland Government or healthcare, but is common in Government funded information technology projects globally across multiple domains (Mergel, 2016). Queensland Health's risk aversion was due to a history of information technology implementation project failures. ...
... Hızla değişen ve belirsiz ortamlarda liderlik yapılarını ele alan araştırmaların çoğunluğu çevik liderliğe vurgu yapmaktadır (Homey vd., 2010;McKenzie & Aitken, 2012;Lawrance, 2013;Parker vd., 2015;Mergel, 2016;Coleman, 2017;Hayward, 2018;Joiner, 2019;Kostrad, 2019;Abbasi & Ruf, 2020). Araştırma sonuçlarından hareketle, çevik liderliği VUCA dünyasında sahip olunması gereken bir beceri olarak belirtmek mümkündür. ...
Bilgi ve teknoloji alanındaki hızlı gelişmeler, değişen müşteri talepleri, çalışma koşulları, çalışan beklentileri, ekonomik dalgalanmalar, son dönemdeki pandemi ortamının getirdiği belirsizlikler gelecek dönemler için planlama ve öngörü yapmayı zorlaştırmaktadır. VUCA olarak ifade edilen bu ortamlarda yeni yönetsel yaklaşımlara evrilmeye ihtiyaç vardır. Bu yaklaşımlardan birisi çevik liderlik ve becerisi ile algılamasıdır. Bu araştırmada çevik liderlik becerisi algısını belirlemeye yönelik bir ölçme aracı geliştirmek amaçlanmıştır. VUCA algısının çevik liderlik becerisi algısı üzerindeki etkisi araştırılmıştır. Araştırmada geliştirilen ölçeğin çevik liderlik becerisi algısı ile ilgili yapılacak çalışmalara ve örgütsel davranış alanına katkı sağlayacağı değerlendirilmektedir. Araştırma TR 62 (Adana–Mersin) Bölgesindeki özel sektörlerde faaliyet gösteren işletmelerde çalışanların katılımıyla gerçekleştirilmiştir. Araştırma sonucunda çevik liderlik becerisi algısını belirlemeye yönelik geçerli ve güvenilir bir ölçek geliştirilmiştir. Değişkenlik algısının çevik liderlik becerisi algısı üzerinde pozitif etkisi bulunmuştur. Bu doğrultuda, çalışanların değişkenlik algısı arttıkça çevik liderlik becerisi algısının arttığı ifade edilebilmektedir. Değişimin karşısında örgütlerin çevik kabiliyetlerinin geliştirilmesine dönük olarak, başta liderlik olmak üzere örgütsel yeteneklerin geliştirilmesinde karar verme prosedürlerinin daha esnek hale getirilmesi ve kurumsal çözüm üretme kabiliyetinin hız tabanlı olarak geliştirilmesi gerekmektedir.
... While these digitization efforts are intended to contribute to time and resource savings, they continuously replicate existing offline processes without rethinking mission support or redesigning services for citizens willing to accept them as a trusted alternative. In addition, new forms of agility and responsiveness in delivery services are emerging that focus on co-design and co-production approaches with the public (Mergel, 2016). ...
Full-text available
Digital transformation has been effectively applied in the public sector in Vietnam, especially the ministries. This fact has received significant attention from scientists. Therefore, to supplement the evidence of previous studies and enrich the research literature, this study examines the impact of factors of the digital transformation capacity of public servant of Vietnam Ministry of Home Affairs (Moha) on their task performance. This study was conducted through a cross-sectional survey using an intentional sampling technique (n=200). A multivariate linear regression analysis technique was applied to prove the hypotheses. Research results show that all three factors, digital technology capabilities, digital transformation ethics, and digital transformation leadership, have a positive and meaningful impact on the task performance of Moha public servant. Among them, the most substantial impact belongs to digital technology capabilities. Therefore, this study implies that the Vietnamese government and the Moha need to pay attention to formulating policies to improve the digital transformation capacity of public servant in digital transformation.
Within only 10 days of March 2020, the Swiss administration had designed and implemented a loan guarantee scheme for enterprises. The implementation phase was also short: it lasted less than five months. This article examines how that was possible, considering the complexity of the institutional setting and the scheme's innovative form, especially in terms of IT, including breakthroughs for the Swiss e-administrative practice: the scheme used algorithms to verify clients’ applications, a unique identification number for companies was implemented on a large scale, Swiss banks were integrated into the project's preparation and implementation, and some of their client operations were centralised on a government e-platform. The salient features of the process are identified through an analysis of the unfolding of operations during those ten days. The circumstances and context leading to radically new forms of public governance are also identified. Besides, an output analysis was undertaken to single out the innovative features of the deliverable. The case under consideration was short, and came unpredictably, so that no data or observations could be collected before or during the case. Accordingly, the study is by and large based on ex-post enquiries. With no explicitly formalised mandates, structures, or roles, the project participants came up with an informal organisation system. A well-defined deliverable was a powerful driver of the process. Several characteristics of the project, such as efficient networks, real-time information flow, flexible roles, flat hierarchy, and swift iterative subprocesses were akin to those of ‘agile organisations’. Tasks were performed concomitantly instead of sequentially. Points for practitioners It is striking that not much scholarly research has been published so far with a view to collecting and sharing the ‘lessons learned’ from the unique experience of emergency support packages during the pandemic, including at intra-organisational level. Research could be done regarding replicability both for future emergencies and for adjusting normal-times public management practices. This proposal aims to contribute to this conversation with a view to inspiring practitioners in public administrations and government entities. It foregrounds the relationship between governmental crisis management and the digitalisation of public administration processes using computer-enabled tools.
Despite decades of digitalization in day-to-day government operations and in the governance of the public sector, there is a major research gap in understanding the nature of digital government leadership (DGL) and th diversity in how top managers are leading the digital transition and transformation of government. Based on a structured literature review and in-depth inductive analysis of previous research within the domains of e-government, information systems, and public administration research, this article explores how the C-suite level of government is leading the digitalization. In the article, we propose a definition of DGL and a leadership framework to capture the nexus and direction of leadership. Also, the article proposes distinct leadership roles and actions to forward digital government.
Large-scale government digitalisation projects require collaborative approaches for their successful development and implementation. To shed light on these collaboration dynamics, the interplay between two integral parts of collaborative projects: the project rules, procedures, and structures (collectively known as institutional design) and the leaders managing these projects is studied. In doing so, the paper provides empirically grounded insights into the management of collaborative government digitalisation projects. Taking an institutional perspective, and the strategic-relational (SRA) approach, we examine the extent to which institutional design constraints leadership behaviours, and under what conditions leaders begin to adjust and/or challenge these design features adding to the knowledge of managing digitalisation of government. To this end, we present a five-country case study of national digitalisation projects across Europe. Our results show that while clear institutional design features such as established rules, project structures, and standard operating procedures are essential at the initial stages of the projects, leaders' skills in understanding and tailoring these features are critical to handle project-related problems and moving forwards towards implementation. This underscores the importance of examining projects taking an SRA approach and the need to understand leadership behaviour in the context of the structures in which it is embedded.
Full-text available
Understanding why employees go the extra mile at work is a key problem for many organizations. We conduct a field experiment at a medical organization to study motivations for employees to submit project proposals for organizational improvement. In total, we analyze 1237 employees, 118 proposals, and quality evaluations for more than 12,000 evaluator-proposal pairs. The analysis shows that solicitations offering a personal reward for top submissions boost participation rates without affecting submission quality. We show that this is due to workers partially internalizing the positive effects of their submissions on the other individuals in the workplace. We also find that offering employees project funding to implement their own proposals potentially backfires, undermining participation. And solicitations emphasizing mission-oriented goals, like improving patient care, are sensitive to the solicited person's gender, with women responding more than men. These results shed light on the factors that drive employees’ engagement in organizational tasks, beyond regular duties, and provide insights on how to design incentives to foster contributions to public goods inside organizations.
Conference Paper
Full-text available
This paper proposes the Digital Public Service Innovation Framework that extends the " standard " provision of digital public services according to the emerging, enhanced, transactional and connected stages underpinning the United Nations Global e-Government Survey, with seven example " innovations " in digital public service delivery – transparent, participatory, anticipatory, personalized, co-created, context-aware and context-smart. Unlike the " standard " provisions, innovations in digital public service delivery are open-ended – new forms may continuously emerge in response to new policy demands and technological progress, and are non-linear – one innovation may or may not depend on others. The framework builds on the foundations of public sector innovation and Digital Government Evolution model. In line with the latter, the paper equips each innovation with sharp logical characterization, body of research literature and real-life cases from around the world to simultaneously serve the illustration and validation goals. The paper also identifies some policy implications of the framework, covering a broad range of issues from infrastructure, capacity, ecosystem and partnerships, to inclusion, value, channels, security, privacy and authentication.
Conference Paper
Full-text available
Governments and citizens operate in a digital environment, leaving digital trails whatever they do and wherever they go. These trails generate huge quantities of information about themselves, each other and any interactions they have. In this context, the most important elements of an organization that deals with people are the information it can access and the intelligence provided by analysis of that information. Information and intelligence generate capacity for innovation, efficiency and the agility to adapt to a rapidly changing environment. These statements are as true for public as for private organizations; most governments in the 21 st century industrialised world and beyond are reliant on a large digital presence and complex network of large-scale information systems for administrative operations and policy-making. These systems go beyond being critical for policy implementation to shaping the whole context within which policy and service delivery choices are made, either facilitating innovation or constraining policy options. Simply put, many or even most government departments and agencies 'are' their information systems and digital presence – the only part of them with which many citizens will interact (Margetts, 1999; Dunleavy, Margetts et al, 2008, Steinberg, 2012). Yet those that direct, manage and study government can find it bewildering to negotiate this rapidly changing information environment or to prioritise the interactions and feedback loops that would capitalise on the potential of the internet and digital technologies for public policy solutions and service delivery, particularly in the prolonged period of austerity following the financial crash of 2008. Consequently, the online worlds of governments and citizens remain strangely separate and distinct. The state can lag behind technological trends endangering its operation. As driverless cars become a reality, for example, the technology available to service them far outstrips the development of the legal framework to govern their use or allocate responsibility, for example when two driverless cars crash.
Organizations are expected to adapt within a short time to deal with changes that might become disruptive if not adequately dealt with. Yet many organizations are unable to adapt effectively or quickly due to the established institutional arrangements and patterns of decision-making and governance. Adaptive governance should enhance the capacity of an organization to deal with and adapt to changes, while protecting the same organization from becoming unstable. Strategies of adaptive governance include utilizing internal and external capabilities, decentralizing decision-making power, and seeking to inform higher-level decisions from bottom-up. At the same time, adaptive strategies may challenge stability and accountability, which remain essential for governments. This means that adaptive governance implies a ‘balancing act’, and a reliance on ambidextrous strategies. The aim of this editorial is to introduce the concept of adaptive governance and discuss its implications for governments in the digital age.
Drawing on two case studies in the UK public sector our qualitative study explains how and why open source software has seen such a mixed response. Our narratives indicate that for both cases there was strong goodwill towards open source yet the trajectories of implementation differed widely. Drawing upon ideas of change(ing), mutability and materiality we unpack the process of adoption. The study shows that open source software has certain facets; code, community, coordination mechanisms, license and documentation. Each facet is not stable; indeed, it is changing and mutable. This creates possibilities, potential but also recalcitrance, and barriers. The interesting point of departure of our study is how open source software — a much touted transparent and open phenomenon — is by its nuanced and layered mutability able to make the process and practices surrounding it less visible. It concludes with clear policy recommendations developing from this research that could help to make open source adoption more sustainable in the public sector.
Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster. In the past 12–18 months, a wide range of publications—Software Development, IEEE Software, Cutter IT Journal, Software Testing and Quality Engineering, and even The Economist—has published articles on what Martin Fowler calls the New Methodology (see, reflecting a growing interest in these new approaches to software development (Extreme Programming, Crystal Methodologies, SCRUM, Adaptive Software Development, Feature-Driven Development and Dynamic Systems Development Methodology among them). In addition to these "named" methodologies, scores of organizations have developed their own "lighter" approach to building software. Formation of the Agile Alliance On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, 17 people met to talk, ski, relax and try to find common ground. What emerged was the Agile Software Development Alliance. A bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants. Although the Manifesto provides some specifics, a deeper theme drives many Alliance members. At the close of the two-day meeting, Extreme Programming mentor Bob Martin joked that he was about to make a "mushy" statement. Though tinged with humor, Bob's sentiments were shared by the group—we all enjoyed working with people who shared compatible goals and values based on mutual trust and respect, promoting collaborative, people-focused organizational models, and building the types of professional communities in which we would want to work. The agile methodology movement is not anti-methodology; in fact, many of us want to restore credibility to the word. We also want to restore a balance: We embrace modeling, but not merely to file some diagram in a dusty corporate repository. We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who brand proponents of XP, SCRUM or any of the other agile methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term (a "hacker" was first defined as a programmer who enjoys solving complex programming problems, rather than someone who practices ad hoc development or destruction).