“Agility is the ability to adapt and respond to change; agile organizations view change as an opportunity, not a threat.”

Jim Highsmith

Overview

The citizen development hyper-agile SDLC is different from traditional or agile SDLCs. It extends on the principles of agile delivery by identifying unique characteristics of citizen development to optimize quicker decision making and lighter project governance. It transforms how software is developed and reshapes how development teams are assembled and operate, with business resources taking the lead and minimal IT approvals required.

What makes it hyper-agile?

1.It delivers on the promise of design and development as a single activity, removing the need for extensive requirements gathering, multiple handoffs, and unnecessary documentation.

2.Smaller teams, real-time development, and lighter governance result in less management overhead and release capacity within the organization.

In this section, we discuss the three decision pathways to delivery that are based on the complexity and risk associated with creating the solution.

Hyper-Agile SDLC in Practice

A delivery initiates with business autonomy up front, including ideating, scoping, and prototyping. Touchpoints with IT are minimized as a principle, but the citizen developer must have a strong awareness of when and why IT should be consulted.

Guidelines for citizen development project delivery

1.Citizen developers develop according to the least reasonable number of IT stage-gate approvals.

2.Citizen developers have a responsibility to understand the purpose and benefits of IT control and if/when/why IT should be consulted (we explain the IT policies and standards in Section 5.1).

3.Citizen developers are not bound by lengthy project charters and administrative controls prior to prototyping.

4.Minimum documentation is required.

5.Citizen developers possess broad freedom to ideate and prototype.

6.The business retains autonomy for all ideation and solution design.

7.The business considers business/operational risk and value early in the SDLC.

8.Design and implementation of the operating model (maintenance and change management) happens in parallel with application design.

9.Citizen developers are bound to quality assurance, resilience, and security controls.

10.Citizen developers enlist the support of IT developers only when appropriate.

Application development life cycle

The citizen development SDLC has been designed to cater to projects of varying ambition, scale, and complexity. The IT spot assessment is the decision point that determines which path the project squad must follow before it is able to publish the application. Citizen developers carry out the suitability assessment, value tree assessment, and operating model design for post-deployment maintenance.

The preferential order for organizations that wish to truly embrace the citizen developer ethos is as follows:

1.Fast track

2.Assisted

3.IT delivery

See the development life cycle in Figure 3.

Choosing the suitable SDLC path

To choose the suitable SDLC path, citizen developers must assess their projects against two variables: risk and technical complexity.

As a general rule, projects that can be delivered using citizen development present low to medium risk and low to medium technical complexity, as depicted in Figure 4. The remaining area in the figure refers to projects that present high risk or high technical complexity. These projects have to be delivered by IT.

Having said this, it is not possible to create a one-size-fits-all diagram for every organization using citizen development. The boundaries between the areas in Figure 4 are indicative. Some organizations can be more tolerant to risk than others. Moreover, what is considered as high technical complexity for organization A can be deemed medium for organization B, possibly because citizen developers in the latter organization have stronger skills or can address the governance concerns around citizen development in a safer manner.

With the objective of successfully qualifying the citizen development projects versus the IT projects, newly certified citizen developers should have the support of other experienced citizen developers, the competency center, or the IT department.

Risk assessment

There are several categories to evaluate in order to determine whether a project is of low, medium, or high risk. These categories are explained in Table 3.

Technical complexity

The horizontal axis in Figure 4 relates to the technical complexity of the project; that is, how difficult it is to:

•Build the application (create the data models, functionality, and front end),

•Integrate it with the wider IT landscape (applications and databases), and

•Create the user interfaces.

In other words, Figure 4 indicates how proficient the developer must be to achieve the desired quality (either a citizen developer or traditional IT developer).

Inexperienced citizen developers are better suited to projects with low technical complexity that follow the fast track path. If the concerns around complexity can be mitigated by partnering with or getting guidance from experienced citizen developers or IT architects, the inexperienced citizen developers will be able to use the assisted path.

More experienced citizen developers will be trusted and empowered to take on more technically complex endeavors. They can build applications with an increasing number of features and functionalities and integrate them with other existing software or databases.

Fast track path

The fast track path is characterized by light-touch governance and is the path a citizen development squad would take when a project is considered to be low risk and low in technical complexity. Emphasis is on iterative ideation, design, build, and deployment with continuous business feedback loops.

The SDLC allows organizations to favor (and utilize) the fast track path as often as is appropriate. The percentage of projects that can be moved through the fast track is a measure of the maturity of the citizen development culture and the technical capability within an organization.

Assisted path

The assisted path is followed if, after the initial assessment, the initiative is deemed to be of medium technical complexity and low risk. The citizen developer can solicit the support of the competency center and its practitioners. This allows the citizen developer to progress relatively quickly without extensive IT engagement. It could be that the citizen development squad is able to build an MVP, at which point they engage with technical experts in order to finish the application and prepare it for the live environment.

IT delivery path

When the fast track and assisted paths are not suitable for the project as this would present high risk or high technical complexity, the project must follow the IT delivery path. At this point, the project must become IT controlled. However, the citizen developer can still be involved in this scenario. The citizen developer utilizes IT policies, standards, and resource support to ensure the application is delivered into the business appropriately.

Stages and tasks to perform

As described previously, citizen development would be performed when a project presents as low risk and low in technical complexity. Table 4 informs citizen developers about the tasks they must perform at every stage.

Transition to support and change management

Generally the citizen developer—with the support of the business—designs and implements a support model in parallel with the application design and implementation. This includes ownership, support service models, and ongoing maintenance procedures.

Organizations will adopt an operating model that works for them. The role of IT and the citizen developer will differ based on the organization's boundaries and structures. We cover this in more detail in Section 4.2. Our preference is as follows:

•Citizen developer: Configuration and administration of the application

•IT: Management of back-end database and any integrations or underlying platforms

When developing via the IT delivery pathway, standard IT support and maintenance processes will be followed.

Citizen-developed apps generally consist of maintenance changes and enhancements.

Maintenance classifications are:

•Corrective: A fault occurs and maintenance tasks are performed to rectify it so the application can be restored to operational parameters.

•Adaptive: The environment changes and maintenance tasks are performed to modify the application in order to adapt to the new situation.

•Perfective: New enhancements are added to the application that are either functional or nonfunctional.

•Predictive: Scheduled maintenance tasks are performed to maintain the application, detect possible defects, and fix them before a fault occurs.

For maintenance, corrective and adaptive maintenance reside with the citizen developer (most of the time). Perfective and predictive should be, for the most part, the responsibility of the competency center or IT department.

Enhancements:

When a proposed change does not qualify as one of the maintenance classifications mentioned previously, it is considered an enhancement. Enhancements circle back to the SDLC (as illustrated in the SDLC diagram).

This distinction is important, as it has a broader implication in most organizations; maintenance is typically treated as an operating expense (OpEx), whereas enhancements are treated as capital expenses (CapEx) and, therefore, are treated differently with respect to planning, budgeting, and prioritizing.