Agile: A New Way of Governing 1
Public Administration Review ,
Vol. 00, Iss. 00, pp. 1–5. © 2020 by
The American Society for Public Administration. DOI: 10.1111/puar.13202.
Agile: A New Way of Governing
Abstract: The evolving concept of “agile” has fundamentally changed core aspects of software design, project
management, and business operations. The agile approach could also reshape government, public management, and governance in general. In this Viewpoint essay, the authors introduce the modern agile movement, reflect on how it can benefit public administrators, and describe veral challenges that managers will face when they are expected to make their organizations more flexible and responsive.
G
overnment agencies are creating policies for agile government and introducing new practices and playbooks (e.g., GAO 2012;
HUD 2018). For instance, digital rvice teams such as the U.S. Digital Service, the United Kingdom’s Government Digital Service, and the Canadian Digital Service have paved the way for working in an “agile way.” State and local governments have adopted agile and related practices through innovation labs and civic rvice design teams (e.g., Georgia Technology Authority, New York City). In the specific cas, “agile” is a paradigm for better software development and project management to avoid large-scale project failures at the end of the project and funding period (e.g., Mergel 2016; Project Management Institute 2017). Agile is ufully contrasted with the traditional “waterfall” method, in which each project pha has to be carried out in quence (e, e.g., Whitford 2020). Government software projects are designed and built to last for a long time. Planning and building often takes years—and working software is often outdated when it is finally relead. Agile project management values and techniques allow project teams to work on smaller increments, review their work often, and include feedback right away to avoid costly failures.
珠海旅行
A quiet government transformation is already underway among practitioners who are investing heavily in working in agile environments and applying agile approaches to software development and other types of government problems. Traditionally, major changes in the way government works are introduced either through policy changes or through public management reforms. Agencies are now changing their project
management techniques and even procurement practices, incorporating new values and methods that are foreign to classically “bureaucratic” organizations. Historically, only emergency managers typically had to deal with crisis situations in an agile way to respond to shifting realities on the ground. In both practice and academic ttings, people often u “agility” interchangeably with more familiar terms such as “responsiveness” or “adaptive governance”—highlighting momentary change from the standard operating procedures and leading to a conflation of the terms (e.g., Jansn and van der Voort 2016; Wi 2006). Moreover, the canonical public administration literature has largely neglected agile and the more fundamental changes it introduces to hierarchical and bureaucratic organizations. For instance, our arch in Web of Science for the topic “agile”
revealed 26 rearch articles in “public administration,” most of which were not related to the agile concept.Bad on years of collective experience interviewing practitioners and documenting the c
hanges, this Viewpoint essay aims to introduce the agile concept to the public administration community, bringing clarity to the u of the concept and integrating it with other more established concepts in public administration such as responsiveness, resilience, and adaptability (in contrast with more monumental public management reforms such as New Public Management) (e.g., Greve et al. 2019). For clarity, academics can think of agile as a new package of routines and process embedded within formal work groups and structures—as a pathway for “nudging” organizational behavior toward higher-valued outcomes. We proceed by describing its roots in the field of software design. We then highlight key advantages and challenges of an agile working environment in government beyond its origins in software development.
What Agile Is and Why It Matters Agile is such a recent phenomenon that most governments are still learning how to apply it when
Ines Mergel
Sukumar Ganapati
Andrew B. Whitford University of Konstanz Florida International University
University of Georgia
Andrew B. Whitford is Alexander M. Crenshaw Professor of Public Policy in the School of Public and International Affairs at the University of Georgia. He is also a fellow of the National Academy of Public Administration. His rearch concentrates on strategy and innovation in public policy and organization studies.Email: aw@uga.edu
Sukumar Ganapati is associate professor and former director of the PhD program in public affairs at Florida International University. His rearch focus on the u of information
technology in the public ctor. His rearch projects have been supported by the National Science Foundation and the IBM Center for the Business of Government.Email: ganapati@fiu.edu
Ines Mergel is professor of public
administration at the University of Konstanz, Germany, and a fellow of the National Academy of Public Administration. She conducts rearch on digital rvice transformation in the public ctor, the u of nontraditional technologies, and innovative forms of collaboration with public ctor stakeholders.
Email: l@uni-konstanz.de
苗仲华
Viewpoint Article
Table 1Core Values of Agile
1. Individuals and interactions over process and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
arching for innovation and performance improvements in government operations and rvice provision. Agile government is inspired by agile software development, but in wider administrative parlance, it means responding to changing public needs in an efficient way. In the redesign and digitalization of public rvices, agile methods are applied in the initial requirement analysis. Service designers u ethnographic methods to understand ur needs along the journey they take to access a public rvice. They interview process owners (to understand the formal requirements bad on the law) and internal and external urs (to understand their experiences throughout the full ur journey). This reveals pain points but also things that work well, which shows how to design
a better public rvice from a ur perspective.
Service designers then compare the informal requirements幼儿园户外游戏
with the formal requirements and hand over a prototype to the software developers. The design steps emphasize inclusiveness and transparency—not only with respect to citizens but also with respect to public rvants, who rve as core project team members and are not left out of decision-making process. In contrast, in “waterfall” or other traditional approaches involving vendors, contract officers help decide the product’s attributes but rarely solicit the input of tho who u the tools daily. Urs, when they are involved at all, provide feedback or asssment information after a new process, software, or approach is deployed. In contrast with a traditional bureaucracy, in which decisions are made top-down and complaints from urs emerge bottom-up, agile government procedures reframe traditional decision-making by making internal and external urs part of the process from day 1.
Therefore, agile is not in inherent conflict with democratic or other classical administrative values. In internal project management, agile is a method for improving the efficiency of rvice delivery. Yet agile governance implies being responsive to public values such as equality and social responsibility.
This is becau even if agency officials only care about how they deal with external urs, agile shapes how the agency discovers and then integrates the changing needs of the public—itlf a democratic value (Beck et al. 2001). Rather than focusing only on the provision of products or rvices, agile deeply values the voices of both team members and citizens. When prent at all levels of the agency, successful lf-governing agile teams prepare and make decisions, with the broad support
草红花的功效与作用
of top management; this creates greater openness to the broader adoption of successful reform elements (Greve et al. 2019).
The concordance of agile and classical public administration values can be en in the role of the “Agile Manifesto” in the movement’s evolution (Beck et al. 2001). In 2001, a group of software engineers and developers articulated four core agile values that they wanted to guide efforts to fix common problems in how virtually everyone builds and deploys complex software (e table 1). Agile’s core values were established as a way of changing how software is produced. It is easy to e the main points here: urs and makers are the main starting points; software should work first (even if not comprehensive); collaboration gets more done than a conflict-bad process; and, change is inevitable, so responsiveness and adaptability are key.
From the four values, the architects of agile developed 12 key principles for software developers to follow when building and deploying complex software projects (e table 2). The four values and 12 principles establish an infinite feedback loop. Developers are asked to figure out what the software should do, how it should be designed, and how it should be built and to test it all at the same time. Working software produced quickly is the most valuable outcome. Urs then test that build as a way of guiding developers about what changes will most improve the overall project. Tho ur experiences as they interact with prototypes show developers what aspects they should fix first. After rapidly deploying new versions of working software to the ur ba, they then gather new information about what should be fixed next. The overall point here is that this cycle should take as many iterations as needed to make ur experiences better—and it may be that the feedback loop lasts forever.
Becau agile centers on working and learning from customers about how to build better software—about finding what core needs should be fixed next—it is easy to e how people in government have latched on to this approach for improving software development in the public ctor. For instance, a 2014 IBM Center for the Business of Government report (Gorans and Kruchten 2014) focud on how waterfall approaches (the most common way government builds software and, inde
ed, most programs and projects) are rigid in their laying out of project requirements (often taking years) before they move on to the actual design, development, testing, and deployment of working software.
While waterfall is slow and plan bad, agile is fast and light. Agile invests in initial planning but assumes that tho plans will change as experience with working software provides new information about what urs need. In many ttings, tho learning experiences are carried out by teams organized as “scrums” known for high-paced, rapid iteration, perhaps even with the goal of producing new versions of working software in less than a day. While waterfall approaches center on planning, agile succeeds when working software is deployed. Agile projects have four times more success and one-third fewer failures than waterfall projects (Serrador and Pinto 2015; Standish Group 2015); this balance indicates why so many people are drawn to agile as a way of doing their work.
In some important ways, agile’s core assumption is that innovation is not linear—that it does not proceed in a rational, deterministic manner (e.g., e, Mackenzie and Wajcman 1999). Organizations, cultures, and needs are entwined when moving forward with an innovation; in many ns, the process from beginning to end
is path dependent and builds on the actions and preferences of builders, operators, and end urs.
Agile embeds this understanding—either purposively or intuitively—in its focus on rapid learning, which naturally means that agile requires high levels of collaboration between technical staff and the ur ba. For this reason, we now e agile as a way of
2Public Administration Review • xxxx | xxxx 2020
doing more than just designing and deploying working software. Indeed, agile has evolved from a software design method to a central way of handling the design, production, and deployment of any customer-facing process and includes not only information technology specialists but also generalists, managers, and process owners at the ur level. In this respect, while it is impossible
to escape the social shaping of technology, agile respects tho process.
Becau of its roots in and permeation of software design and deployment (to the point that it is difficult now to find software shops that are not agile in some shape or form), we e agile as more than just a way of making apps or bots. Yes, agile has continued to evolve—many organizations now u higher-level integrative practices (e.g., DevOps) for the continuous integration and delivery of co
de—but we e the bigger picture here as this new focus on all customer-facing process. We know that “customer” is a loo word—in fact, urs, employees, citizens, stakeholders, and any word we want to u can be the target of an agile design method to improve government—yet agile works for both internal and external urs.
Advantages of Agile
Overall, agile is a mind-t that initiates a cultural change
in bureaucratic command and control organizations. Agile administrations are open to reforms, adaptation to the changing environment, public values, and public needs. Here we outline how it can contribute to a more effective and efficient administration.
Agile Assumes Situations Are Fluid and Change over Time
As new information, constraints, or opportunities emerge, agile drives practitioners to revi and update early working versions to improve process or rvices. Improvements might include speed to delivery, product or rvice quality, or the program’s existence itlf. While in traditional process “results” are often mostly about “reporting,” in agile the goal is to satisfy constituents by solving their
problems (outcomes are achieved) rather than just producing detailed documentation. Transparency and accountability are improved by knowing why things changed and who was in the room when decisions were made.
Agile Privileges Adaptive Structure over Hierarchies and Silos Unlike in traditional bureaucracies, in which administrative divisions are the meat and bones of everything, in agile, administrative divisions are only for back-end purpos. External urs do not know (or even need to know) administrative constraints. In this way, agile is like other cross-functional administrative arrangements intended to improve transparency, resource sharing, and capabilities. Like other arrangements (e.g., matrix designs), agile is intended to make it easier to know what works and avoid what does not work. In agile, policy or product designers need the input of urs, citizens, or customers becau their own experiences are not as uful or reprentative—so they have to leave their silos. In veral ways, this is what also lay behind the move toward single points of contact instead of dealing with multiple agencies for resolving issues (e.g., permitting in local governments, 311 call centers). In agile, coordination should be amless at the front end.
Agile Emphasizes Responsible Individual Discretion over Bureaucratic Procedures
Rather than following traditional standard operating procedures, workers with experti are liberated to solve public problems
in an efficient and effective manner. As discusd earlier, agile emphasizes bottom-up change over top-down direction (or even outside-in from vendors or consultants). Of cour, this focus
on the individual resonates with broader approaches to change management. Agile’s emphasis on the individual can improve public rvants’ engagement if the organization’s culture values individual contributions. In agile, no worker is just “another cog in the wheel,” which changes the perceptions of tho who are involved and might increa ownership and, subquently, acceptance during the adoption.
Agile Emphasizes Continuous Self-Reflective Learning Process
Agile assumes failure, so agencies that experience failure in their first iterations are better equipped to improve. Therefore, public managers are pushed to abandon a zero-failure culture so that workers are free to make mistakes. Of cour, trial and error and experimental approaches can be difficult in environments that traditionally do not reward mistakes. Likewi, managers drive the process. For instance, agile “retrospectives” require managers and teams to revisit policies and procedures period
ically to ask what happened and how things can improve. Agile cultures learn fast from past mistakes.
Agile Increas Knowledge about Process, Procedures, and Requirements for New Process and Services
We know that agencies with agile purchasing process—often “blanket purchasing agreements” (BPAs)—learn more about what
Table 212 Principles of Agile
1. Seek to fulfill the customer’s needs. Do so through the early delivery of software. Continuously improve that software.
2. Respond to the demand for changes to that software becau doing so better positions the customer for success.
3. Shorten the timescale for the delivery of working software. Deliver changes frequently.
4. Developers should work hand in hand with business urs.
袖手旁观意思5. Center fabrication around individuals motivated to succeed.
6. Emphasize face-to-face conversation within the team and between the development team and the broader organization.
7. The most important benchmarks are working software.
8. Sustainable development is the goal. All involved parties should be able to maintain a constant pace of engagement.
泣涕零如雨9. Continuously focus on technical quality and good design.穿条纹衣服的男孩
10. Emphasize simplicity.
11. Self-organization in teams improves design and production.
12. Regularly reflect on how to improve this process.
Source: Beck et al. (2001).
Viewpoint 3
they need and how things should work. For instance, coauthoring and adapting buying requirements for products and rvices often improves overall quality. In agile BPA process, contract managers verify legal prerequisites, but knowledge owners (who need to u the products and rvices) write content requirements. This helps ensure that products and rvices are usable while maintaining oversight. Urs then asss what external contractors deliver. In domains such as information technology, many vendors are required to follow agile principles in their work with private ctor entities, so an agile layer in the government ctor is de rigueur. In turn, many agencies now require agile buying approaches, including the delivery of prototypes up front to demonstrate ability to deliver on tenders and improve transparency. We are already eing this change in the rvice delivery industry (although it is still early stage days) (e.g., Whitford 2020). Challenges in Adopting Agile in Government
We e veral key challenges in importing agile into traditional agencies, especially in scaling new practices or experiments to the rest of the organization.
Agile Is Antithetical to Many Typical Bureaucratic Line Organizations
In the ttings, managers who need to take responsibility for actions may not be willing to do so gi
书法之美ven how cross-functional agile teams work. This is classic blame avoidance—a natural respon in risk-aver ttings when people are asked to take responsibility for new methods and especially their outcomes. If experimentation is not part of the toolbox, and if bureaus value organizational reputation and avoid public failures, agile never gains traction. Managers need to take responsibility for the final product and defend the outcome, even though it might not have been developed with their explicit input. Agile civil rvants cannot rely on established standard operating procedures, so their actions run headlong into legalistic administrative culture. Becau agile can also contradict administrative law, its application must be evaluated ca by ca. Moreover, in organizations largely characterized by “we have en this before, let’s wait until the next wave comes in,” traditionalists could e agile as another fad that will be replaced.
Agile Requires a New Form of Leadership
Most notably, agile requires connsual decision-making and acceptance of trial-and-error approaches—leadership styles that are not often reprented among middle managers. Agile requires handing over decisions to groups of nonleaders; agile requires protection of teams from external political and other influences.
In a number of ways, agile is consistent with rvant leadership, which is less-reprented in public administration (Greenleaf 1970). Agile emphasizes putting subordinates first, helping them grow and succeed in the organization, empowering the team, and creating value for the community. Many private ctor information technology companies using agile emphasize rvant leadership.
Agile Requires New Forms of Contracting and Procurement Traditional contracting process are oriented toward waterfall, which focus on the delivery of specified products in a stepwi fashion. Agile does not quite fit the traditional process since there is not a single finished product, process, or rvice—the thrust is on continuous improvement. Agile requires a contract management approach that is flexible and stretches beyond a fixed-price, one-time project. Such new modes of contracting and procurement focus on the holistic team, rvice delivery process, and creating long term trust relationships (Opelt et al. 2013).
Conclusions and Future Opportunities
Agile requires at its core a change in rigid bureaucratic cultures (top-down, zero failure). This is no small feat. Generations of civil rvants have been trained to follow the hierarchy principle. They have been told to obey a command and control structure without questioning the legitimacy of its dec
ision-making model. They have learned to stick to their guns in assigned roles and leave innovation up to the upper echelons. Change in organizational culture is hard, especially if there are no incentives to change. We know that there are many internal organizational and cultural features that influence the changes and the adoption of new reform elements (Greve
et al. 2019; Jun and Weare 2011; Venkatesh et al. 2003).
Agile culture turns traditional organizational principles of the bureaucracy upside down. Agile values individual team members
and teams. It requires responsible discretion—and great flexibility in organizational procedures and principles. Many organizational ttings have experienced remarkable transformation through the application of agile principles. The same is possible in the public ctor—if leaders embrace its advantages and are mindful of its challenges. Here, empirical rearch together with practitioners is necessary to understand the expectations of organizational members, such as necessary competences, decision-making structures, or expected outcomes.
Yet we recognize that the are early days for our understanding
of the prospects for agile in the public ctor. For instance,
one area ripe for theoretical and empirical contributions is the political aspects of agility. We know from our collective empirical understanding of the practice space that theoretical or empirical contributions that dintangle agility in policy making, agility
in emergency policies, or other types of proactive or reactive policy-making issues would be beneficial. An obvious example is that emergency management or public health respons may be especially attuned to agile principles. However, the development of such a contribution is beyond the scope of this short essay. Another area that needs greater elaboration is how agile practitioners e the relationship between the framework they know best and the broader classical public administration values elaborated in this journal and taught in public affairs programs. A number of methodologies (e.g., Q-sorts) could be ud to elaborate that relationship but to our knowledge no systematic information is currently available.
Even though our knowledge ba remains incomplete, the practice experience makes clear that agile is gaining traction as a new way of governing. We hope that this contribution helps build a bridge for further collaboration between practitioners and academics in the arch for new ways of enhancing public value.
References
Beck, Kent, et al. 2001. The Agile Manifesto. Agile Alliance. agilemanifesto.
org/ [accesd April 30, 2020].
Gorans, Paul, and Philippe Kruchten. 2014. A Guide to Critical Success Factors in Agile Delivery. IBM Center for the Business of Government. www.
4Public Administration Review • xxxx | xxxx 2020
businessofgovernment/sites/default/files/A%20Guide%20to%20Critical%20 Success%20Factors%20in%20Agile%20Delivery.pdf [accesd April 30, 2020]. Greenleaf, Robert K. 1970. The Servant as Leader. Newton Center, MA: Robert K.
Greenleaf Center.
Greve, Carsten, Niels Ejersbo, Per Lægreid, and Li H. Rykkja. 2019. Unpacking Nordic Administrative Reforms: Agile and Adaptive Governments. International Journal of Public Administration 43(8): 697–710.
Jansn, Marijn, and Haiko van der Voort. 2016. Adaptive Governance: Towards
a Stable, Accountable and Responsive Government. Government Information
Quarterly 33(1): 1–5.
Jun, Kyu-Nahm, and Christopher Weare. 2011. Institutional Motivations in the Adoption of Innovations: The Ca of E-Government. Journal of Public
Administration Rearch and Theory 21(3): 495–519. doi/10.1093/
jopart/muq020.
Mackenzie, Donald, and Judy Wajcman, eds. 1999. The Social Shaping of T echnology.
Buckingham: Open University Press.
Mergel, Ines. 2016. Agile Innovation Management in Government: A Rearch Agenda. Government Information Quarterly 33(3): 516–23.
Opelt, Andreas, Boris Gloger, Wolfgang Pfarl, and Ralf Mittermayr. 2013. Agile Contracts: Creating and Managing Successful Projects with Scrum. Hoboken: Wiley. Project Management Institute. 2017.
Agile Practice Guide. Newtown Square, PA: Project Management Institute. Serrador, Pedro, and Jeffrey K. Pinto. 2015. Does Agile Work? A Quantitative Analysis of Agile Project Success. International Journal of Project Management
33(5): 1040–51.
Standish Group. 2015. CHAOS Report 2015. / sample_rearch_files/CHAOSReport2015-Final.pdf [accesd April 30, 2020]. U.S. Department of Housing and Urban Development (HUD). 2018. Agile Methodology Policy. December 11. v/sites/dfiles/OCHCO/ documents/34301CIOH.pdf [accesd April 30, 2020].
U.S. Government Accountability Office (GAO). 2012. Software Development: Effective Practices and Federal Challenges in Applying Agile Methods. United States Government Accountability Office. GAO-12-681. v/ asts/600/593091.pdf [accesd April 30, 2020].
Venkatesh, Viswanath, Michael G. Morris, Gordon B. Davis, and Fred D. Davis.
2003. Ur Acceptance of Information Technology: Toward a Unified View. MIS Quarterly 27(3): 425–78. doi/10.2307/30036540.
Whitford, Andrew B. 2020. Transforming How Government Operates: Four Methods for Changing Government. IBM Center for the Business of
Government. www.businessofgovernment/sites/default/files/
Transforming%20How%20Government%20Operates.pdf [accesd April 30, 2020].
Wi, Charles R. 2006. Organizing for Homeland Security after Katrina: Is Adaptive Management What’s Missing? Public Administration Review 66(3): 302–18.
Viewpoint 5
