4b. Agile development

This section will help you:

Work with and support a vendor as they run an agile development process

Embed software in the organization’s technical environment by incrementally deploying working software modules and evaluating them

Collaborate with the vendor to produce thorough technical and user-oriented documentation

Common challenges

You may encounter these frictions as you do the work of agile development. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.

Staff turnover

Staff retention can be a significant challenge, particularly for technical expertise—where city governments have to compete with private sector software companies for talent. Staff turnover can confuse the process, cause delays, and compromise continuity.

Lack of familiarity with or lack of involvement in the agile development process

City staff assume that they cannot or should not be involved with the developer team. Coders should have decision-making power when it comes to technical architecture, timelines, and required effort, but they do not know what end users need. The best software will result from good collaboration.

Lack of communication with end users

Frontline staff members—the end users—will be affected by continuous integration. It is important to notify them of changes to their daily workflow, and to seek their feedback throughout the development process.

Lack of input from technical experts when sprint planning

This can result in over-specifying or under-specifying feature sets and poorly planned budgets and timelines.

Recommended actions

1. Supporting the agile work plan

Your software development partner will create a high level agile development plan. This plan will describe the overall technical architecture of the project, showing how a number of independent and interoperable modules will fit together to address the problem statement. You can support the planning process in a number of ways.

Agile might feel uncertain—and that’s ok

An agile development project is only planned in broad strokes at the outset. The point is to be incremental and iterative, to accommodate changes based on what you learn as you go. This reduces overall risk of failure, and minimizes expensive and time-consuming revisions in the future.

Provide the development team with documentation

Have a meeting to walk them through the problem statement, user journeys, success criteria, and KPIs. Answer any questions, and ask them if they see any gaps in the discovery research or if they have ideas to add.

Review the full feature set with the development team

Ask if they have any concerns or additions.

Review your organization’s technical environment with the development team

Discuss the technical architecture for the project, and resolve any questions about how it will fit into your organization’s existing systems. Another important topic is how DevOps will happen, and how you will give feedback (make sure an IT professional from your organization attends).

Schedule demos

Your RFP specified that the development process would include deployment into the actual working technical environment. This gives you an opportunity to demo working software to end users and get their feedback. Schedule these sessions early, so that they are sure to happen.

2. Sprint planning

Your development partner will be building software modules quickly, in 2-4 week sprints. These should be scoped, budgeted, and contracted individually, underneath the umbrella contract.

Each sprint is about building a module that is...

Based on insights from the discovery research

Written out as a clear user journey

Planned and resourced according to complexity and necessary staff effort

Developed in a short (2-4 week) sprint

Fully operational at the end of the sprint

Integrated, tested and operationalized at the end of the sprint

Work with the development team to plan the first sprint.

(see guidelines below)

Guidelines for agile sprints

Each module should addresses a very specific problem that a future user will face. For example, a web application for trash removal may include:

“I am a resident. I need to know which day trash will be collected this week, and whether it will be trash + recycling or recycling-only.”

“I am a trash truck operator. I need a route for pickups at the beginning of every day.”

“I am a waste management services operator. I need to know if severe weather conditions are expected, and notify residents of service delays.”

Sprint planning and scope should be determined with the development team. Some teams use a simple point-scoring system to assign an amount of work involved to complete each sprint (e.g. “1” for a simple module and “4” for a complex module). This helps with staffing, budgeting and planning. Before each sprint, work with the development team to plan the focus, scope, and timeline of each sprint.

Agile development depends on regular meetings. The development team will meet frequently (usually every day). If an external vendor is doing the development, there should be a meeting with the client at the end of every sprint (every 2-4 weeks).

3. Using a DevOps approach

DevOps (short for “Development and operations”) involves continuously deploying software modules in the actual working environment as they are built. That means launching a piece of software on the city’s servers and having users start using it in their daily workflow. Your job is to organize the deployment, testing and feedback for each module along the way.

DevOps reduces risk

By deploying and testing, you can identify any technical or procedural incompatibilities and fix them along the way. It also means that key staff become familiar with the product, and have opportunities to provide feedback that helps guide future modules or sprints.

Include deployment and evaluation in the contract for each sprint

Allocate time and budget for this step, and specify KPIs or success criteria. You are in control of the quality!

Coordinate with end users to evaluate the module

Do this after it’s been integrated into their daily workflow. They are the best resources for evaluation. If it isn’t functional from a technical or user standpoint, then it isn’t good enough—you can do another sprint to refine it.

Evaluating modules

You should be using iterative, module-specific contracts under an umbrella contract. You have the opportunity to evaluate each module, and can discontinue the umbrella contract in the event of underperformance. Ask the following evaluation questions:

Does the module meet the sprint’s KPIs?

Does the module address a user journey that is relevant to the problem statement?

Is the product logical and usable for the end user?

Does the product integrate with the city’s existing digital environment?

Did the process align with the optional criteria, values and objectives in the RFP?

Was the product delivered in a timely manner?

Takeaways

Create or complete the following outputs before moving on to the next step.