Agile for Sustainable Modernization in Government

Posted on June 5, 2019 in Government Digital Transformation, PFM

Is agile project management and product development a sustainable approach to government modernization?

It’s a technology practice inflection point. Widely adopted by the tech giants, the majority of development teams and projects now embrace agile methodology, while pure waterfall approaches are in the minority. We have found that agile can be particularly effective in change management.
Is agile appropriate for government? Can agile scale up and out? Can agile momentum grow?
Our experience shows that agile is financially and reform sustainable for complex Enterprise Software deployments in government.
Agile processes promote sustainable development according to Agile Manifesto principles. The purpose of this blog entry is to explore how agile enables sustainability in government reform and modernization.
Some important points about the state of agile:

• Agile is more than software development, techniques like Kanban cover all types of project
• Agile techniques for country development, like Problem-Driven Iterative Adaptation (PDIA), have become mainstream
• Agile can be applied to adapting software over time, although bi-modal IT approaches for systems maintenance are most appropriate
• Agile can include a number of techniques such as design thinking, DevOps, and Scrum

How can we measure sustainability?

There’s a reason why we called this blog “the sustainability blog”. Many Government Resource Planning (GRP) systems have become financially unsustainable. Other GRP systems have been unable to adapt to government reform legislation. That’s why we believe that financial and reform sustainability are the two elements to measure for any IT system in government, including GRP.
Financial sustainability is about long-term affordability including:

• Total Cost of Ownership (TCO) for the entire system lifecycle on 10 or more years including environmental costs (see appendix)
• Internal support costs for government staff to maintain, support, and upgrade systems including additional talent, training and retention costs, that is often not included in TCO calculations (see appendix)
• Technical debt in the form of potential cyber, resilience, and integration risks that may not be immediately evident, including hidden costs (see appendix)

Reform sustainability is about the ability for systems to adapt to government reform:

• Progressive activation of built-in features and configuration for business rules and workflow
• Extensibility to support a broader range of functionality by reusing what exists (leveraging the existing investment also makes systems more affordable)
• Technical scale where systems can scale up to support more organizations and more users

Agile processes support these definitions of sustainability by:

• Reducing development, support, maintenance, and upgrade costs
• Leveraging existing investments through experimentation
• Identifying limitations in current investments quickly
• Identifying which processes benefit from agile, and those that do not with the bimodal approach to manage costs and risks
• Extending the experience to use agile in
• Improving predictability through iteration progress measurement

What is the government sustainability context?

The sustainability context is different in the public sector. These should be considered when implementing agile in government:

• Higher turnover in the civil service than in the private sector
• Lower capacity in the civil service than in the public sector
• More stakeholders in government than in business
• Fewer acknowledged “best practices” in government than in business
• More change in government though elections and revolution than in business
• More change hurdles in government than in business because of political incentives and need for legal reform

We are often asked whether our systems and processes are sustainable after we leave a country. We believe in helping governments achieve self-sustaining systems and processes. But, we don’t think that abandoning governments with “turnkey” solutions after payment is received is a socially responsible approach.
We believe that capacity building is socially responsible. We believe that providing operational government work after implementation should be an exception. We use our steering committee to cover governance and reform trends to help governments predict capacity building needs.
The primary sustainability problem that we encounter is the loss of country ownership over reform. This results in uncoordinated sporadic reform operating in silos.
We believe that vendors and advisors need to find process methods to empower government ownership. To help governments to lead reform. From a push to a pull model.

Agile techniques provide tools to better understand problems over time, better identify solutions to problem, and adapt solutions to scale. For example, the Province of Ontario Method Cards can be used to support user-centric design, diagnose digital readiness, and articulate problems.
Continuous learning is another agile benefit that enables solution sustainability. Agile processes enable measurements at short intervals. Agile also enables experimentation with prototypes and A/B testing. This scientific approach reduces costs while optimizing results. The value-for-money is maximized.

What has been the agile experience in government?

Governments have been late to agile adoption but are now witnessing significant benefits. The U.S. federal government TechFARHandbook identifies the following benefits to agile:

1. Improvement in investment manageability and budgetary feasibility
2. Reduction of overall risk
3. Frequent delivery of usable capabilities that provide value to customers more rapidly
4. Increased flexibility
5. Creation of new opportunities for small businesses
6. Greater visibility into contractor performance

You’ll note that 5 of these 6 benefits have sustainability implications:

• Manageability via agile reduces maintenance costs
• Risk reduction via agile reduces hidden costs
• Value optimization and faster time-to-results via agile increases value
• Flexibility via agile enables solutions that better address problems
• Visibility and transparency into contractor performance, and internal performance, increases value

Agile in government is not just for small projects. Agile is effective in solving big government IT project problems. The United States Digital Service, for example, has overcome significant IT project failures through agile, including stabilizing and improving Healthcare.gov.
Agile has matured to enable scale. Scaling agile has become the norm. This includes prescriptive frameworks such as Scaled Agile Framework (SAFe), Large Scaled Scrum (LeSS), Disciplined Agile Delivery (DAD), Nexus, the Spotify model and a plethora of others. The top benefits from agile studies point to process sustainability:

• SAFe claims of 30-75% better time to market, 10-50% improved employee engagement, 25-75% improved productivity, 20-50% improved quality, all of which point of high potential sustainability
• One study found top benefits of agile were ability to adapt to changing processes (78%), and greater collaboration (62%) where process sustainability is enhanced through adaptation to future changing processes with collaboration and working together
• Another study found top benefits of agile were enhanced ability to manage changing priorities  (69%) and  project visibility (65%) where process sustainability is enhanced through adaptation to future changing processes and transparency
• A third study found the top benefit of agile was enhancing collaboration (54%) where process sustainability is enhanced through collaboration and working together

What has been the agile experience in country development?

Problem-Driven Iterative Adaptation (PDIA), a public-sector and country development methodology, addresses this complexity challenge. PDIA was developed by the Building State Capacity facility of the Harvard Kennedy School of Government. This is much more than an academic exercise with numerous case studies in the real world. It’s part of the Doing Development Differently movement. We’re big fans of PDIA. Many of our executives have taken Executive Education for PDIA. Many of our staff have taken online PDIA courses.
PDIA is an agile and iterative approach. Principle number 3,  try, learn, iterate, adapt shows PDIA as an agile method.  Scale through diffusion, principle 4, shows how PDIA can scale.

Other aspects of PDIA that demonstrate sustainability include:

• Many governance reform initiatives fail to achieve sustained improvements in performance because organisations pretend to reform by changing what policies and organisational structures look like rather than what they actually do
• Construct locally-driven problems … it is a more sustainable approach because it infuses legitimacy into change processes that inherently generate a contentious mix of “winners” and “losers”.
• PDIA is about building and sustaining broad coalitions of stakeholders, at both the political and implementation level, working toward a shared goal.

How does agile align with GRP system sustainability?

The general approach to GRP implementation is waterfall. Waterfall assumes that these projects are fully predictable. They are not anywhere near as predictable as waterfall needs. Tight adherence with RFP requirements and specifications leads to implementations that do not address government problems nor support reform objectives.
A recent paper from the Inter-American Development Bank found that the trend is to strengthen the user focus of IFMIS, both by encouraging greater participation in system design and implementation (through user committees) and by improving usability and providing adequate services and training. These benefits extend to sustainability. In particular, improved usability reduces the need for unnecessary training. Agile just-in-time agile training improves functional and technology capacity.

Where does agile not help sustainability?

Agile is not the magic bullet for GRP sustainability. There are some constraints to consider:

• Agile is not always agile: many methodologies are rebranded as agile meaning that there are few sustainability benefits.
• Sprinting is not sustainable: the agile method of running sprints to delivery more functionality quicker should be an exception.
• Agile capacity needs to be built: culture change is necessary, particularly in government, to leverage agile benefits – as one study found: despite a will to be Agile, there is a gap between good intentions and actual capability
• GRP solutions chosen matters: some software is heavily configurable or uses low code approaches to facilitate post-implementation reform, while custom-developed software and legacy ERP systems generally do not.

Appendix – Calculating Financial Sustainability, Total Cost of Ownership and Technical Debt

This appendix summarizes 3 previous blog entries, augmented by observations about the role of agile.
A 2012 FreeBalance blog entry describes how to calculate TCO for GRP systems. This covers the TCO problem in Enterprise Software and government. Acquisition and implementation costs are described. We’ve found that software license costs are often not material to the overall implementation costs compared to services. And, the total implementation costs can be dwarfed by total post-implementation costs. Many governments seek new core or subsystem GRP solutions within 5 or 7 years because of increasing technical debt. The blog entry described the footprint for on-going and hidden costs.

On-Going Costs

• Maintenance costs for all hardware and software purchase, which includes vendor customer support. This is typically an annual contract.
• Government personnel acting as first line support for equipment and software. This also includes case management to track bugs and enhancements while maintaining the vendor relationship
• System tuning of databases, operating systems and networks as number of transactions increase.
• Changes to configuration and customization of reports or forms accomplished by internal staff or consultants.
• Bandwidth, telecommunication, electricity and rental/lease/space costs.
• New fiscal year processing including carry-over of previous year funds accomplished by internal staff or consultants
• Upgrade costs associated with moving to newer software versions. This includes change management to ensure that any customization accomplished in the previous version is added to the next, testing and acceptance.

Hidden Costs

Total costs change through the lifecycle of GRP usage where implementation costs are higher that additional year steady state. Additional per year costs can mount because of software upgrades, government modernization and unexpected costs.

• Lost productivity as systems are run in parallel and the employee learning curve.
• Reduced efficiency by adding so-called “best-practices” that adds complexity to existing processes.
• Change management costs for new government regulations and training on processes within the software.
• Disaster, lost data, business disruption through late implementation or system failures including audit and reporting disruption.
• User conference and training travel and expenses charges to keep up-to-date on software changes.
• License audits where vendor demands additional payments
• Maintenance options may require additional payment to achieve necessary service to overcome problems.
• Unexpected add-ons when product portfolio does not meet entire requirement.
• Middleware changes such as operating system or databases outside the GRP system upgrade period.

Sustainability implications of agile

• Agile improves maintainability (including system upgrading) while enabling adaptability when compared to traditional methods with faster execution
• Agile improves system support through problem-driven approaches that delve beyond symptoms
• Agile is resilient to reform changes through iteration

A 2015 FreeBalance blog entry described technical debt in GRP, or Financial Management Information Systems. The entry described the signs of technical debt as:

• The more FMIS different subsystems (budget preparation, payroll, procurement, accounting, assets etc.) operating on different technology platforms (4GLs, .Net, Java, proprietary etc.) reduces extensibility, increases maintenance costs, limits integration and restricts reform (because of the need to duplicate functionality across multiple systems such as a change in budget classifications)
• The more systems are custom developed or customized COTS represents significant costs to maintain and upgrade – this can be determined based on the amount of internal IT support and external consultant required to operate, troubleshoot, adapt and upgrade
• The amount of manual intervention required to complete the entire budget cycle including manual steps, manual duplication, and the preparation of analysis and reports on spreadsheets separate from FMIS systems

Sustainability implications of agile

• Agile improves maintainability (including system upgrading) while enabling adaptability when compared to traditional methods with faster execution
• Agile identifies problems associated with manual and duplicate systems through journey mapping

Another 2015 FreeBalance blog entry described the nature of software investments and impact of technical debt and system extensibility. Technical debt is characterized by the use of legacy and custom-developed software in government that restricts change. This is particularly problematic in government where there is a need for on-going Public Financial Management reform. Information systems that cannot easily adapt to change become financially unsustainable. Another sign of technical debt is when a significant portion of the IT budget is associated with keeping the “lights on”. The blog entry introduced a framework to identify technical debt risks.

1. Coverage: Vendors with point solutions do not have extensible software. Buyers should be wary of vendors who fill Public Financial Management (PFM) functionality with private sector software particularly in areas like budget planning, payroll and procurement where government requirements differ from significantly from those in business.
2. Reusability: Modern software design uses object-oriented programming for reuse. Small components are assembled to provide functionality. This differs from legacy design where large or monolithic objects were created with duplicate functionality that cannot be easily assembled.
3. Metadata: Unified design means the ability to change something once. Many vendors have acquired applications and require complex metadata management tools to ensure that definitions remain consistent.
4. Integration: Full support of industry-standard web services simplifies reuse and extensibility. Proprietary and flat file integration methods introduce technical challenges.
5. Openness: The more open a system is designed, the easier it is to extend. Open systems reduce lock-in. Some vendors attempt to lock-in buyers with proprietary databases, operating systems and programming languages.
6. Adaptation: Systems that are not designed for easy change increases cost when attempting to support PFM reform. The need to contract highly-priced consultants or the original software development vendor increases technical burden.
7. Platform: There are many vendor definitions of a “platform” from a technology platform to a full business platform. A full Commercial Off-the-Shelf (COTS) business and technology platform like the FreeBalance Accountability Platform the necessary reuse among components.
8. Language: Many enterprise software vendors use proprietary programming languages, often developed during the client/server era. This limits choice to a narrow group of consultants who are able to develop new features and take advantage of any extensibility in the software.

Agile improves reusability and adaptability through experimentation and scaling solutions that work.