a. Welcome!
- 
- 
- 
- 
- 
+ 
- 
- 
- 
+ 
+
+
+
+
+
+
+ 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. +
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+
+
+
+
+ Collaborative agile development
+
+
+
+
+ 
+ 
+
+
+
+ Modular budgeting
+
+
+
+ 
+ 
+
+
+
+ + DevOps continuous integration and testing +
+
+
+
+
+ Further reading
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 1.
+
+
+ 18F
Agile Principles
+
+ 2.
+
+
+ Atlassian
+ Five agile KPI metrics you won't hate +
+ +3.
4.
5.
+
+
+ Canadian Digital Service
CDS Product Evaluation Framework
+
+ 6.
7.
+
+
+ 18F
Product Guide: Work with the vendor
+ +8.
+
+
+ Agile Alliance
Agile 101
+
+