Agile Facilitates Government Change Management

Posted on March 1, 2022 in Government Digital Transformation

Is agile the magic bullet for government project success? We’re agile advocates because of improved success rates using agile product development, agile project management and agile country development. Our methodology, A-i³+qM is built on proven good practices and almost 40 years of exclusive government implementations.

How is Change Management Related to Agile Methodology?

Agile techniques, when adapted to government, integrate change. Beyond software change management to true organizational change. Government Resource Planning (GRP) software is configured to meet real requirements effectively.

When properly practiced, agile engages stakeholders early and often. Change resistance dissipates as issues addressed and progress proven. As Jason Little observes, “Agile isn’t about “Agile”, it’s about change“.

Change management in government is particularly critical in the implementation of new financial, human resources, procurement, or performance systems. In the Cynefin framework (diagram above), the implementation of GRP is beyond technical. It’s not simple, even though many would hope that governments follow “best practices“. Many of these practices are inappropriate for the government context at the time.

And, implementing a GRP is far more than just a software change management project. It’s transformational. There are legal reforms, new processes, reorganizations and new performance measurements that have to take place.

The goal in GRP implementations is to support good practices, making implementations complicated. The reality is that implementations become complex, sometimes chaotic, because of unique public sector constraints:

• Stakeholders extend beyond government to citizens
• Public service capacity and incentives
• Politics, politics, and more politics

How is Change Management Integral to Agile?

Although there are numerous agile techniques, (see glossary below), organizational change management in the public sector has been implicit since the creation of the Agile Manifesto. Manifesto values show how people, collaboration, and flexibility is paramount.

• Individuals and interactions over processes and tools: frequent interaction with stakeholders and users reduces change resistance while increasing likelihood that real needs addressed (An agile principle: “business people and developers must work together daily throughout the project.”)
• Working software over comprehensive documentation: documentation does not lead to shared understanding with stakeholders and users – frequently delays implementations giving time for change resistance to increase (An agile principle: “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”)
• Customer collaboration over contract negotiation: collaboration gives voice to stakeholders and users
• Responding to change over following a plan: context is learned through conversations, not through rigid planning

How to Get Agile Change Management in Government Right

Agile operates well when trust is enabled and encouraged. Agile enables change management in government when properly managed:

• Consideration: agile techniques like Design Thinking and PDIA encourages empathy and understanding problems from stakeholder and user perspectives
  • IMPACT: stakeholders and users realize that systems aren’t imposed by outsiders
• Customer-Centric: agile works from the customer out (what we call “outside-in” in product management) rather than product in (what we call “inside-out” in product management)
  • IMPACT: stakeholder and user fears and aspirations become baked into projects
• Communication: constant communication keeps stakeholders and users up-to-date through boards and other visual communications methods to demonstrate decisions, progress and backlogs
  • IMPACT: stakeholders and users less prone to imagine the worst between milestones, where progress is visibly communicated
• Conversation: face-to-face conversations with stakeholders and users including workshops, brainstorming, and storyboards
  • IMPACT: stakeholders and users recognize ability to adjust project deliverables while learning more about the project value to them, their organization, and their country to increase change acceptance
• Context: the country and government context becomes understood by project teams (and, FreeBalance has tools to enable this process)
  • IMPACT: shared understanding among participants is enhanced to reduce change resistance
• Collaboration: project teams, stakeholders and users work together to set priorities, solve problems, and discuss solutions
  • IMPACT: influence on the project through involvement increases change acceptance
• Creativity: leverage stakeholder and user creativity to better solve problems
  • IMPACT: stakeholders help solve problems  including change problems
• Confirmation: collaboration gives participants confirmation of project priorities throughout the project rather than sign-offs at major milestones as sole avenue
  • IMPACT: project delays reduced because of iterative confirmation, giving little time for change resistance to build, while feedback loops validate stakeholder and user concerns
• Capacity: government project and governance domain capacity built during conversations and collaboration as mentoring, augmenting training and improving project success
  • IMPACT: sustains organizational change trajectory beyond the project (and makes project more sustainable)

Why Do Governments Resist Agile Change Management?

Some government customers ask why we involve non-experts in solution design. Demonstrations seem to be the best approach to communicate the impact of agile to improve decision-making and organizational change management in the public sector. In addition to using agile for implementations, we’ve used agile exercises at our annual FreeBalance International Steering Committee (FISC), change workshops and country context exercises.

The change in attitude among public servants is palatable. At first, suspicion. Maybe a bit of confusion. Then, collaboration and conversation. It gets to the point where every working group wants to present findings to the workshop. Real collaboration.

What is the Organizational Change Management Process?

Traditional organizational change management processes tend to be a linear sequenced way as described by the 5 I’s:

1. Initiation
2. Investigation
3. Intention
4. Introduction
5. Implementation
6. Integration

Another approach designed by John Kotter:

These are excellent frameworks for organizational change. The linear approach, however, seems to align with traditional waterfall approaches. Just like agile can align with the CMMi and ISO standards, there’s no reason why these approaches cannot be leveraged iteratively. Iteration may improve change outcomes, just as software development and project management success rates improve through agile.

We’ve seen some projects where organizational change management in government was considered an add-on to project management. This often results in “drive-by” and ineffective change management.
It makes sense to have change experts on projects. There is often a disconnection when change experts lack domain expertise. So, it’s more effective to have change integral to projects. To have project staff building change and credibility.

What are the Benefits of Using Agile Change Management in Government?

Reed Deshler sees the need for a real-time approach to change management in agile projects. This includes adapting understood change management processes to be “fit for purpose” for individual projects. A study by Prosci analyzed change management practices in agile projects. The analysis found that successful change management in agile projects requires:

• Iterative approaches rather than linear
  • OBSERVATION: all project components are iterative in agile, and the impact of change management is continuous to build change acceptance
• Change plans designed to adapt
  • OBSERVATION: change plans should change as project participants learn more about context through conversation and collaboration – consider this as adapting to feedback looks
• Requires more upfront time
  • OBSERVATION: agile provides the communications framework for change to facilitate planning, while more change planning comes through less project planning and documentation – where change management becomes a higher priority

Our experience with agile in the real world is that it generates the kind of quick wins needed to maintain change buy-in. Agile provides visible steps between the quick wins thanks to involvement, flexibility, and prototyping. We’ve benefited from the product design of the FreeBalance Accountability Suite™ thanks to configuration methods that enable confirming business rules and configuration in workshops. This enables the kind of agile development not available in fully customized government software or heavily customized private sector software like Enterprise Resource Planning (ERP).

PDIA Approach to Agile Change Management in Government

As described earlier, the organizational change management context tends to be more complex in government than in business. Problem-Driven Iterative Adaptation (PDIA), a public-sector development methodology and excellent change management tool addresses this complexity challenge. PDIA is becoming more accepted in the good governance and country development community.

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 prioritizes change and persuasion, enables mapping roles and communications strategies. Stakeholder mapping, communications and collaboration is built into PDIA.

PDIA enables analyzing the change space: the overlap of authority, ability and acceptance. This is a particularly strong change management technique. As described in the Doing Development Differently Manifesto: success comes through legitimization “at all levels (political, managerial and social), building ownership and momentum throughout the process to be ‘locally owned’ in reality (not just on paper).”

PDIA recognizes that substantial change doesn’t depend on the heroic leader. Successful change in the public sector comes from many leaders. These are agents. This goes beyond the traditional approach of change agents to scaling agents. Scaled change is presented with a snowflake metaphor.

What is the FreeBalance Agile Methodology?

Our methodology has iterated over the years. The current version is A-i³+qM (accelerated, integrated, iterative, implementation-focused, quality management):

• Accelerated by eliminating as many legacy waterfall processes that lead to project problems. This includes unnecessary documentation and detailed project plans, in favour of workshops and short process steps. Team sizes are kept small to enable client communications and reduce coordination overhead.
• Integrated through a single methodology to support development and services implementation. This is integrated with customer requirements through the customer-centric processes. This provides transparency between the customer staff, the implementers, and the development team. Implementation and product development teams are integrated following DevOps practices.
• Iterative to be responsive to customer and implementation changes using phases. The methodology leverages the best of proven “lean” software development and services methodologies with workshops, short iterations, user stories, milestones and the ability to show progress. These techniques are extended beyond the development organization to implementation services leveraging productivity gains and ability to react to customer requirements.
• Implementation-focused with good practice templates and proven program management processes. This methodology is focused on the success of the customer implementation, rather than a software release that achieves internal or arbitrary goals. Implementation and product development are managed via a Program Management Office.
• Quality approach ensures that the software is released and supported meeting Commercial Off-the-Shelf (COTS) good practices with unit, system, stress and regression testing. Quality is integrated with implementation where FreeBalance tests based on customer environments.

A-i³+qM recognizes the deficiencies of traditional project management processes in GRP implementations. And, the patterns of failure.

Agile Glossary

All definitions, except for PDIA, via wikipedia.org

• Adaptive software development (ASD) is a software development process that grew out of the work by Jim Highsmith and Sam Bayer on rapid application development (RAD). It embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
• Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).[1] It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
• Design thinking refers to the cognitive, strategic and practical processes by which design concepts (proposals for new products, buildings, machines, etc.) are developed by designers and/or design teams. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts.
• DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.
• Disciplined agile delivery (DAD) is a process decision framework that enables simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including Scrum, agile modelling, lean software development, and others.
• Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method.
• Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
• Feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software.
• Iterative and Incremental development is any combination of both iterative design or iterative method and incremental build model for development.
• Kanban (Japanese 看板, signboard or billboard) is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.
• Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the Agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.
• Large-scale Scrum (LeSS) is a product development framework that extends Scrum with scaling rules and guidelines without losing the original purposes of Scrum.
• Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing (i.e. algorithmic) concepts.
• Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology services from Microsoft. MSF is not limited to developing applications only; it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology (such as the waterfall model or agile software development).
• The Personal Software Process (PSP) is a structured software development process that is intended (planned) to help software engineers better understand and improve their performance by bringing discipline to the way they develop software and tracking their predicted and actual development of the code. It clearly shows developers how to manage the quality of their products, how to make a sound plan, and how to make commitments. It also offers them the data to justify their plans.
• Problem-Driven Iterative Adaptation (PDIA) is a a process of facilitated emergence which focuses on problems (not solutions) and follows a step by step process (not a rigid plan) that allows for flexible learning and adaptation, designed by the Building State Capacity facility of the Harvard Kennedy School of Government.
• Rapid-application development (RAD), also called Rapid-application building (RAB), is both a general term, used to refer to adaptive software development approaches, as well as the name for James Martin’s approach to rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even in place of design specifications.
• The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003.[1] RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.
• The Scaled Agile Framework (abbreviated as SAFe), is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. Along with large-scale Scrum (LeSS), disciplined agile delivery (DAD), and Nexus, SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.
• Scrum is an agile framework for managing knowledge work, with an emphasis on software development, although it has wide application in other fields and is slowly starting to be explored by traditional project teams more generally. It is designed for teams of three to nine members, who break their work into actions that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks, then track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums.
• Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban. Today, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work
• SEMAT (Software Engineering Method and Theory) is an initiative to reshape software engineering such that software engineering qualifies as a rigorous discipline. The initiative was launched in December 2009 by Ivar Jacobson, Bertrand Meyer, and Richard Soley with a call for action statement and a vision statement. The initiative was envisioned as a multi-year effort for bridging the gap between the developer community and the academic community and for creating a community giving value to the whole software community.
• In combination with the personal software process (PSP), the team software process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software the principles products that range in size from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code.
• The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process.