[CITY] will foster agile, cross-departmental collaboration to embed continuous learning and innovation in data use.
Modern cities require dynamic, collaborative, and user-centric approaches to working with data. The traditional reliance on project-based, siloed ways of working is no longer sufficient to meet the complex and ever-evolving needs of residents. Instead, adopting agile methods and embedding continuous improvement into daily workflows will ensure that the city remains responsive, innovative, and effective in delivering value through data.
Agile, Continuous Improvement, and Learning Delivery
Agile working methods should be at the heart of how the city approaches its data initiatives. Teams must embrace iterative planning and delivery, releasing smaller increments of work frequently to ensure regular feedback and continuous improvement. This approach allows teams to adjust quickly to new information, shifting priorities, and evolving user needs. This is especially applicable to data-related work that relies on software that is never done. User requirements change every day and a waterfall approach to software will never be able to adapt quickly to the changing needs.
Central to agile delivery is the mindset of continuous learning. Teams should not fear experimentation or failure but instead use these experiences to adapt and improve. Iterative approaches ensure that even incomplete solutions are valuable starting points that grow and improve over time. Software often goes through four phases of development - discovery, alpha, beta and live. These are further elaborated on below:
- In the discovery phase, the goal is to understand the problem and whether users need the service. A clear problem statement that solves a real user’s needs, ensures that resources aren’t used on “white elephant” products that don’t solve anyone’s issues.
- The alpha phase acts as a testing stage, where several solutions are tested to identify bugs and demonstrate that the service is possible. This is a mock-up phase too, to show the user some designs and test whether they would help solve their needs.
- In the beta phase, one solution is further developed to a point where the service can be shared with a wider audience for further testing and feedback.
- The live phase is where the final product has been built and is accessible to all users. Its important to note that this phase doesn’t mean that software is done. The service is still continuously improved based on user feedback, analytics and ongoing user research.
Continuous learning also means that existing processes that increase the time that it takes to deliver software should be continuously reviewed. Policies and procedures in cities can often become “bureaucratic”, adding unnecessary steps into achieving outcomes efficiently. On its own, processes may make sense. However, when added to other policies, they make delivery inefficient and tedious. A process chart is an excellent approach to use when reviewing such policies that every department head or data team should perform. By understanding why each step is done, unnecessary process steps are removed to streamline efficiency and delivery.
Modern data-driven cities must embed GESI principles into agile, iterative development processes. This means ensuring that all user research efforts actively include underrepresented voices, such as informal workers, women, differently-abled persons and people living in informal settlements. Multidisciplinary teams working on municipal data projects will be required to apply gender and inclusion lenses when designing services, ensuring that digital platforms, dashboards, and tools are designed for diverse accessibility needs.
Embedding Design Thinking and Incremental Delivery
To truly serve residents, every data-related initiative must begin with a thorough understanding of user needs. As explored in the ‘User centred data management’ chapter, user engagement ensures that we emphathise with the user and we develop features/products that meet needs. Aligning them to needs ensures that unnecessary resources aren’t spent on developing features that won’t be used by our target audience. The design thinking approach (shown in the figure below) is an excellent resource that showcases how the user engagement process happens. The loops showcase how the steps aren’t linear in practice and often loop back to each other to ensure that we implement what is learnt actively. For example, if at the “testing” phase we learn about new users, the correct approach would be to go back to the “emphathise” phase and engage with those users about the features that are needed.

When implementing the steps above, the two common challenges observed are:
- Not knowing who to engage: A user can vary depending on the service being developed. We want to actively engage the primary user who owns the product development with us and can guide us when to engage secondary users or beneficiaries so that features can meet their needs. Regular communication channels, such as workshops, stakeholder check-ins, and feedback loops, should also be established to maintain alignment throughout the project lifecycle.
- Trying to build everything all at once: Attempting to deliver a fully realised solution in one-go can lead to delays, resource strains, and missed opportunities for early user feedback. Users may want the solution to all their problems all at once, but developing those solutions may take time due to limited resources, leading to unnecessary frustrations. We want to provide users with a testable solution as soon as possible to generate excitement and start solving challenges. Adopting an iterative, agile approach—focusing on small, incremental releases—is critical. Prioritisation is another approach that helps significantly. Users can break down their feature requests into a MoSCoW approach (Must-have, Should-have, Could-have and Would-have). Must-have features are prioritised in early sprints and make up the prototype or minimum viable product (MVP). The rest of the features are moved into a backlog for future development. With software development, the backlog is continuously refined. In fact, users will often have other needs that take higher priority as the test more. Delivering incrementally ensures users benefit early and often from the work being done. Small, frequent releases not only keep momentum but also allow teams to collect actionable feedback to guide future improvements.
To support best practices, the city will maintain a publicly accessible Data Manual that provides clear, actionable standards on how to deliver data-driven projects effectively. Data standards are an important part of this data manual - sharing what “good” looks like in terms of software development. This manual will serve as a reference for teams, outlining standards for ethical data use, interoperability, privacy, and technical excellence.
Shifting from Project to Product Management
[CITY] should transition from project-based technology management to a product-based approach for its data systems. While project management focuses on delivering predefined solutions with fixed timelines, treating completion as the end point, product management emphasises continuous ownership and iterative improvement throughout a system’s lifecycle.
Project-based approaches lead to stagnant systems that require costly periodic modernisation as they fall out of sync with user needs. By contrast, product management ensures systems remain relevant through continuous adaptation, with core teams maintaining vision and direction rather than disbanding after launch.
Success in this transition requires redefining outcomes based on long-term value rather than project completion, placing users at the centre of development, and building internal capabilities that can sustain continuous improvement. By adopting product-based management, [CITY] can create resilient, adaptable technology solutions that evolve alongside community needs.
Working in the Open
Working in the open is a form of governance. Because modern agile ways of working are organised around iterative delivery and incremental change, governance processes need to be too. It also means that people working on data projects in different parts of the city and beyond can find each other without having to navigate management hierarchies.
Transparency is essential to building trust and fostering collaboration. The city must adopt open practices, such as:
- Public Roadmaps: A product roadmap is intended to show a product/service will evolve over time - over months, quarters and years. How features in the backlog will be prioritised. Teams will share their goals and timelines in publicly accessible formats, allowing stakeholders to track progress and align their own plans.
- Show-and-Tells: Regularly scheduled sessions where teams demonstrate their work, share lessons learned, and invite feedback outside of the user space. Show-and-tells can also work as great leverage tools to showcase how incremental delivery is helping users, getting wider support to assist other teams.
- Weeknotes: Weeknotes are a concise way to document your team’s progress, share updates, and communicate next steps to stakeholders or team members. They serve as a regular touchpoint in your project’s governance process, promoting transparency, accountability, and alignment. Furthermore, they can help gather excitement around the work, especially for people who don’t work on the projects daily. They keep stakeholders and other departments connected to the progress, fostering interest and support.
For open data efforts to truly benefit all communities, transparency must extend beyond simply publishing datasets—it must include co-designing data policies with affected groups. [CITY] will establish regular public engagement sessions, where community representatives can review and challenge municipal data practices, ensuring that data use is transparent, accountable, and beneficial to historically excluded communities.
These practices ensure that work remains visible, encourages accountability, and enables cross-departmental collaboration. By sharing successes and challenges openly, [CITY] teams create opportunities to learn from one another and build a culture of continuous improvement.
Action Items
- Adopt agile frameworks across all data-related teams in the city
- Create a role description for key product management and agile delivery roles
- Publish a data manual with actionable standards for data-driven project delivery
- Create a community of practice and hold regular open showcases of the city’s data work
- Review and streamline city policies to eliminate inefficiencies in data project delivery
- Implement a user engagement strategy for data-related initiatives
- Shift from project-based to product-based management for technology related projects
- Introduce weeknotes across all data-related teams for transparency and collaboration
- Establish public roadmaps for data projects and services
- Facilitate regular cross-departmental feedback sessions to ensure continuous improvement