UvA-DARE (Digital Academic Repository) Collaboration, experimentation, continuous improvement: Exploring an iterative way of working in the Municipality of Amsterdam’s Bicycle Program

As demand for cycling rises, cities are scaling up their bicycle planning and infrastructure efforts. There is not only a knowledge gap to building this infrastructure, but also an organizational learning gap, as planning organizations are stepping into new waters. This research investigates how well an agile (an iterative, collaborative) way of working may be well ‐ suited to address this through the case of the Municipality of Amsterdam ’ s Bicycle Program. We explore what this way of working looks like in the bicycle planning context through the stories of Amsterdam practitioners. This is done through 12 semi ‐ structured interviews and 2 narrative interviews with process mapping exercises, the latter of which explore one project in more detail: an intervention at the Alexanderplein intersection. In the Alexanderplein project, collaboration, experimentation, and analysis were tightly connected and enabled learning by the municipality. We present how the way of working in this project and in the Bicycle Program as a whole relate to agile characteristics, practices, and barriers, and we discuss the implications for planning for cycling.


Introduction
There is growing demand for cycling to address accessibility (Kager and Harms, 2017), public health (Fishman et al., 2015;Garrard et al., 2012) and sustainability (Chapman, 2007) challenges. Already experiencing a "renaissance" (Pucher et al., 2011), the onset of the COVID-19 epidemic has thrust the practice further into the spotlight (Budd and Ison, 2020;De Vos, 2020). More people are cycling (Bryant, 2020) and cities have had to respond and create safe places for people to ride (Alderman, 2020) as public transit cannot safely carry the same capacity. In these cities' post-COVID-19 visions cycling plays a bigger role, and they are already taking steps to make that a reality (Cokelaere et al., 2020).
With this rapid scaling-up of cycling, organizations will be stepping into new waters. Urban planners and designers will be attempting to expand bike infrastructure to enable cycling for a broader population (Pucher and Buehler, 2008), and they will need to develop the capacity to do this. There will be local learning and experimentation, and it will need to happen quickly. Planning organizations need to be able to respond in a timely way, learn, and facilitate more cycling. To aid in doing this, it would be helpful to have an understanding of what it is like to work in a way that enables practices and characteristics such as learning, experimentation, and responsiveness.
An "agile" way of working is an iterative, collaborative way of working suited to responding to change. It focuses on collaborating with customers, delivering a working product for feedback, and valuing individuals and interactions (Beck et al., 2001). Some trace its origin back to Francis Bacon in 1620 (Rigby et al., 2016), and it has been in active use in organizations since at least the 1980's, particularly in software development (Abbas et al., 2008;Larman and Basili, 2003). In comparison to the traditional linear approach which is focused on optimization and assumes a predictable environment, an agile one is centered around human collaboration, testing, reflection, and action learning (Table 1). Nerur and Balijepally (2007) point out that the fields of architecture and strategic management have already experienced an intellectual thought shift towards the latter, and that the iterative approach to problem solving is well-suited to complex "wicked problems" (Rittel and Webber, 1973) such as those in urban planning.
The conditions of rapid deployment of cycling infrastructure and the need to scale cycling up to address societal health, climate, and accessibility challenges suggest that it's time for a similar intellectual evolution in planning for cycling. Accordingly, an exploration of what this way of working looks like in the cycling context would be of use. This research provides this, focusing on the following research question: What does an agile way of working look like in the bicycle planning context?
The paper starts by grounding itself in the literature on agile and reviewing prior research on agile in urban planning. It then explains how we used Geels's (2002) multi-level perspective to conceptualize planning organizations transitioning from their current way of planning for cycling to an agile way, and presents a case that showed indications of already working in this way: the Bicycle Program of the Municipality of Amsterdam (Programma Fiets van de Gemeente Amsterdam, in Dutch). We explore this case and a specific project of theirs at the Alexanderplein intersection through the lens of practitioners with 12 semi-structured interviews and 2 narrative interview sessions combined with a process mapping exercise. After reporting back results from the interviews, we discuss implications and reflect on avenues for future research.
2. Literature Review: Agile as an iterative, collaborative way of working Agile is "the ability to create and respond to change… a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment" (Agile Alliance, n.d.). It has become a very popular way to execute projects and provide value for the customer by being more in touch with their needs while spending less time and money (DybÔ and Dingsøyr, 2009;Highsmith, 2002;Pinto and Serrador, 2015). We acknowledge that agile is a label that has significant baggage associated with it. With that said, the ideas behind it provide a useful lens around which to center this research. Drawing from the literature, we define characteristics and practices of an agile organization in Tables 2 and 3.
In urban planning practice, elements of an agile way of working are already emerging (Sadik-Khan and Solomonow, 2017;Scruggs, 2018;Wagenbuur, 2018). The tactical urbanism movement embodies many of its values (Lydon et al., 2015). In urban planning and geography literature, scholars have looked at how cities are increasingly being used as "laboratories" (Evans, 2016;Karvonen and van Heur, 2014) and at the potential of street experiments to trigger transformational change in mobility (Bertolini, 2020). There have also been several conceptual explorations of agile related to planning. Munro (2015) sees agile through the lens of technology and smart cities, Clark (2007) describes agile energy systems and sustainable communities, and Luna (2015) construct a theory of agile governance. Velibeyoglu et al. (2016) explore the application of an agile framework to urban design. Another group of authors directly translates the principles of the agile manifesto (Beck et al., 2001) to urban adaptation (Pathirana et al., 2018;Radhakrishnan et al., 2017).
However, these contributions do not address how the way of working within a planning organization relates to organizational capacity to scale up cycling and improve the bicycling environment. This paper fills this gap by providing an example of an organization that learned and grew its capacity to plan for cycling.

A multi-level perspective on how to enable agile working
We approached this research from the stance that we are providing an exploration of agile working for organizations that are not currently planning for cycling in this way. In order to structure our interviews and break our main research question into sub-questions, we used a theoretical framework on transitions: the multi-level perspective (MLP) as conceptualized by (Geels, 2002). Our rationale here is that an organization that is not currently planning for cycling in an agile way will need to transition to an iterative, collaborative way of working.
From this framework, we identified three conceptual steps needed for the transition to an agile way of working: enable agile to rise into the regime by making it relatable to planning organizations, better understand the context of the planning regime, and learn about barriers that need to be overcome to enable an agile way of working to rise  up into it. Table 4 below shows these steps, along with a visual representation of how each one fits in to the MLP.
To address the barriers that need to be overcome in our third conceptual step and help organize the interviews, we surveyed literature on agile and developed a list shown in Table 5.

Case study
To best explore what an iterative, collaborative way of working looks like in the context of planning for cycling, it makes sense to choose a case that is already (at least partially) working in this way. We selected the Bicycle Program of the Municipality of Amsterdam due to several indications that this was already occurring: the redesign of the Mr. Visserplein intersection (Wagenbuur, 2018), a commission of a desire line study (Copenhagenize Design Co., 2014), and the "Ping If you care!" initiative (Mobiel21 Bike Citizens, 2019) demonstrated they were thinking about how cyclists navigate streets and would adjust designs accordingly. A working group initiated by a prior mobility Alderman-which one of the authors of this paper was involved inshowed efforts to explore a more iterative way of working for cycling. Finally, the location of Amsterdam is well-suited because a significant amount of cycling already occurs there and many people are working on planning for it; thus, there is plenty of substance to study.
We also selected a significant recent project of the Bicycle Program to study in more detail: the turning off of the traffic lights at the Alexanderplein intersection ( Fig. 1). This project started as an experiment to see if flow would improve at the intersection, but ended up changing how the municipality viewed the interaction of bicycle traffic and other modes as a whole.

Methods
Our main method was 12 semi-structured interviews with practitioners. According to Guest et al. (2006), 6-12 interviews is an ideal saturation point-this research reached that point. As this was an exploratory research, semi-structured interviews were an ideal method for "examining uncharted territory" with open-ended questions to get practitioners' independent thoughts (Adams, 2015, pp. 493-494). In order to gain a rounded understanding of the current way of working in the Bicycle Program of the Municipality of Amsterdam, multiple stakeholders that affect the way of working in their own ways were interviewed: planners, program managers, project managers, urban/traffic designers, and people working in community engagement and policy. An item list developed from the conceptual steps in section 3.1 was used to guide the interviews. Interviewees were shown the tables on agile characteristics, practices, and barriers, and were encouraged to elaborate on whatever thoughts came to mind-this was where connections between agile and planning were explicitly made.
We also conducted 2 narrative interviews (Jovchelovitch and Bauer, 2000) with process mapping (Damelio, 2011) exercises that focused on a the project at the Alexanderplein intersection. These helped us both hear stakeholders' personal experiences with the project and build a visual representation of who they thought were the key project stakeholders.
Afterwards, we performed thematic analysis separately for the semi-structured and narrative interviews in line with the phases of Braun and Clarke (2006). We began this by going through the transcripts of the interviews and coding parts relevant to the agile lists of Tables 2, 3 and 5 (characteristics and practices of an agile organization, and barriers to adopting an agile way of working), to the research sub-questions in Table 4, and also anything else that was persistently mentioned, in Atlas.ti software. Thus, the process was in line with the-  Table 4 Research sub questions as steps for research.

Conceptual step & corresponding questions
Visual connection to MLP framework 1 Make agile detectable by wider planning regime: How accessible and relatable is agile to planning departments?
Conceptual step 1 in yellow,step 2 in orange, and step 3 in red 2 Better understand context of planning department: What are gaps between the current way of working and agile in planning departments? 3 Learn about barriers that need to be overcome for an agile way of working to rise into the regime: Under what conditions might agile be adopted by planning departments in practice?
(Image adapted from Geels, 2002, p. 1261, reprinted with permission of publisher) oretical coding (with a pre-determined focus of material), but with part of the openness of inductive coding (Braun and Clarke, 2006). The first round of coding generated initial themes. We then went through the transcripts again with the initial themes in mind, and formed a list of final themes. These ended up relating both to the agile lists and research sub-questions, and to what arose in the case study.
We found that the themes were quite related to each other, and we show them and their connections in the thematic maps in the results section.

Results
Through the reflections of practitioners, this research presents a case of what an iterative, collaborative way of working looks like in the bicycle planning context. We begin this section by presenting how the interviewees identified with agile characteristics and practices. We then share results from thematic analysis of the semistructured interviews (on Amsterdam's bicycle program in general) and the narrative interview and process mapping sessions (the Alexanderplein project).
Overall, interviewees understood and related to most of the characteristics and practices from the agile lists of Tables 2 and 3. This suggests that agile is accessible and relatable to planning departments (research sub question 1). One worker interviewed said, "I think they all make sense, especially this focus on people of course. Because that's what you do it for… To have a plan you always have to ask the people who live there, 'what do you think about it?" Some practices were directly in line with the group's strategy, as one interviewee pointed out for experimentation, iterative work: "We want to do a lot of experiments in the city to see what works and doesn't work and learn from it and maybe change it." Many items were noted as important and led to reflection by the practitioners, such as the responsive characteristic: "This responsive thing is something that I really want to grow in because I really am a planner you know… I first this and then that and then that and it's really hard I think to be this responsive and to react and change." However, for some characteristics and practices there were variations in responses among the interviewees. For example, with selforganizing teams, one person commented "I like to give people a lot of responsibility. And I also like to have autonomy…", while another said, "The self-organizing teams… we're not really working like that yet". For manager is facilitator, one interviewee felt that it was not a suitable approach for their context, while another remarked "the managers have got a lot of responsibilities, but they do not cater for the needs that you have".
We leave more of what interviewees said on the agile characteristics and practices in Appendix A for reference.

General bicycle program
The semi-structured interviews looked at the municipality in general. We found that agile working was partially already happening in the Bicycle Program of the Municipality of Amsterdam. Frequent collaboration, information driving decisions and a focus on people are all already happening. There is also a strong focus on teamwork, especially within small groups. However, there are gaps between the case's current way of working and agile (research sub question 2), notably: in responding to and welcoming change; early, incremental and continuous delivery of a working product; and simplification (maximizing the amount of work not done). We leave additional commentary on all of the agile characteristics and practices in Appendix B.
In terms of barriers that need to be overcome (research sub question 3), top management support and organizational structure stood out as the largest ones to an agile way of working. Top management was described not as intentionally blocking agile as a concept, but as needing to provide practitioners more support in working towards common goals. Organizational culture, new skills needed, and perceptions of agile were also brought up as potential barriers; however, they were not depicted as strong and one interviewee suggested there were no barriers. For some of the items, interviewees gave mixed interpretations-some thought it could be a barrier while others thought that it definitely would not be on their team.
In our thematic analysis of the semi-structured interviews, we found four main themes around the agile characteristics, practices, and barriers, and related to the working conditions found in the case. The first two themes relate to challenges that employees must deal with: balancing numerous interests and stakeholders and changing conditions along with limited time, money, and capacity. Staff have both internal and external customers, and involving a variety of stakeholders is a necessity in order to get things done. The Municipality of Amsterdam is facing societal changes, yet has limited time, money, and capacity. The third theme, collaboration, is a potential solution to address the first two themes. It seems to happen most in small working groups, but it is also necessary to collaborate across departments and disciplines. Agile characteristics and practices relate to and complement the collaboration. The fourth theme is the role of the manager. He or she has a key role in how the first two themes are addressed; however, there are varying perspectives on what this role should be. Many of the interviewees like the idea of the manager as a facilitator that enables employees to get their work done, but some think the manager needs to be strong and provide direction. The themes and sub-themes are shown in Fig. 2 below.

Alexanderplein project
"Everyone was very nervous-you know-they were just biting their nails, waiting for chaos to ensue. And that didn't happen, obviously." (Narrative interviewee) The second part of the research methods-the narrative interview and process mapping sessions-focused on the turning off of the traffic lights at the Alexanderplein intersection. These additional 2 sessions gave research data on a project level, versus on the larger program as in the first part.
The Alexanderplein project was initiated by the municipality as a pilot in consultation with many stakeholders. Research studies accompanied it to measure the impact, including one of intercept interviews from the University of Amsterdam that studied the human experience of people cycling before vs. after the intervention. An interviewee explained that leading up to the intervention, many people did not believe enough was being done in Amsterdam for cycling, and that more was needed. The idea to turn off the traffic lights at Alexander- plein arose inside the bicycle program in this context. The project ended up being an act of learning for the municipality as its ideas spread to other projects, and there was also an impact beyond Amsterdam (e.g. in Rotterdam, the Netherlands (van Vliet, 2016) and Winterthur, Switzerland (Der nackte Ampelwahnsinn oder sinnvolle Verkehrssteuerung, 2018)). The interviewees explained that project occurred in stages, with an initial trial and subsequent re-evaluations and extensions before the intervention became permanent (like the iterative work agile practice). Decisions were made in consultation with many stakeholders (frequent collaboration agile practice) and analysis from research commissioned by the municipality was an important part of them. One interviewee noted the intervention "was actually more intended as a research project than a measure in itself" (experimentation agile practice), but eventually it became its own project. The internal team working on the project was very hands-on and willing to take risks (embraces conflict and welcomes change agile characteristics). It was also noted that the project may not have happened if that wasn't the case. Overall, both interviewees saw the project as a success and the analysis done on the intersection was brought up as an important part of that: "I think it helped to legitimize the change". It showed that the intervention could be done safely, and that people generally preferred the new situation (strong focus on satisfying customer agile characteristic). We leave our commentary on all of the relevant agile characteristics and practices found in the project in Appendix C.
In our thematic analysis, this all came together in three main themes: an iterative project strategy, legitimization through analysis, and maneuvering stakeholders and organization(s). All three are tightly connected. Within these main themes there were sub-themes (visible in the thematic map shown in Fig. 3 below).
Decisions were made in phases, pilots were used to experiment, and awareness of the political context was key (e.g. the CVC (central traffic committee, in English) said it would go ahead with the intervention only if the alderman was ok with it). This iterative project strategy made it easier to deal with complex projects and general worry. For legitimization of decisions through analysis, both qualitative and quantitative data were useful. In maneuvering stakeholders and the organization(s), many administrative layers, a large amount of people involved, and stakeholder needs and dependency were challenges, and professional relationships were an important component.
The whole process of the project also resulted in learning by city staff relevant beyond the project on stress and discomfort that cyclists experience. On a later project at the Muntplein intersection also in the center of Amsterdam, the city had an evolved perspective on how cyclists and road users interact. It was able to use what was learned from the Alexanderplein project in the design of the new intersection.

Discussion
"The traditional goal of optimization and control is making way for learning and innovation" (Nerur and Balijepally, 2007, p. 79) This research explored what an agile (an iterative, collaborative) way of working could look like in the bicycle planning context through the case of the Bicycle Program of the Municipality of Amsterdam and the Alexanderplein project. It interviewed practitioners to see if and how an agile way of working relates to their context, and to explore gaps with and barriers to agile. The research contributes to literature on agile in urban planning and provides a case study of how bicycle planning staff work in one of the world's leading cycling cities. It provides analysis on the accessibility of agile characteristics and practices to this case, and identifies barriers to agile working.
The case of Amsterdam's Bicycle Program showed that despite the reputation of government organizations as rigid and resistant to change, a more iterative, collaborative way of working is possible within a public planning organization. When we dug into the details of this in the Alexanderplein project, we saw that the characteristics and practices of this way of working are tightly connected in project execution. And while we cannot comprehensively report back on the benefits of the approach, we would like to comment further on the last paragraph of the results section with our thoughts on municipal learning beyond the project. We think it is most useful to look at the agile characteristics and practices together to understand how they form a learning process-perhaps that is where they can be most helpful. For example: experimentation leads to learning, learning generates new knowledge, and new knowledge can inform iteration. Reflection and feedback allow this process to continue in loop fashion.
Reflecting on the context of the case, Amsterdam's Bicycle Program was likely at an advantage in this loop due to its program-oriented structure. Its program staff work across many projects and play a more facilitative role in helping a portfolio of project managers integrate cycling initiatives into their projects to reach larger program goals. Instead of managing all the projects themselves, they are more of an outside presence. More investigation into the effects of specific organizational and cultural aspects is warranted. (Tables A1-C2) As more cities work towards their ambitions of a more bicyclefriendly environment, agile working fits the conditions described in the introduction section. From this research case, it appears to be accessible and relatable to people working on bicycle planning. It also offers bicycle planning organizations a way to learn via their on their own path. In contrast to copying and pasting best practices from a manual, we see the value of agile work in the potential for organizational learning (Glaser et al., 2019) and for generating new knowledge about cycling-both contextual and general. As alluded to in the paper's title, part of agile working is about continuous improvement. From this research, we found this relevant not in terms of efficiency of project management (which could be possible, but is another research exercise on its own), but in terms of the longer-term, more qualitative, learning process. As the approach and perspective of the city of Amsterdam have evolved, we see an opportunity to for similar learning in other contexts, to facilitate a shift towards cycling and other human-scaled modes (King and Krizek, 2020). Blake et al. (2020) point out that an overreliance on best practices may impede out-of-the-box thinking and not properly address pressing planning issues. Perhaps an agile way of working is an answer for this. As even the global cycling example of Amsterdam has more to learn about how to plan for cycling, we should not forget about the benefits of new knowledge and the doors it opens. Thus, there is potential for researchers to investigate how agile working and loop-like learning may be relevant not only for context-specific cases with organizational learning gaps, but also for the broader collective cycling knowledge.

Implications for researchers and practitioners
For people working in (with) a public planning organization, we have the following takeaways. First, understand your working context and look for opportunities to intervene. Figure out what is already in your organization and build on it. Consider the political situation and test incrementally. Second, consider your people. Individual people are also important to triggering an iterative, collaborative way of working. Hire, enable, and encourage these people to get working on projects. Third, on a more cautionary note, keep the focus on principles and goals. Praise for the term "agile" was not unanimous this research's interviews, and in some cases elicited a strong negative perception. People attempting to foster agile in a planning organization should be cautious not to force a specific methodology and be aware of pre-existing perceptions of the term. In some cases, a specific framework for agile working is strictly prescribed. Ironically, this sort of strict prescription of one version of a process is not agile (Morris, 2015). Organizational leaders should keep in mind that being certified "agile" is not the end goal. Fourth, this way of working doesn't have to be an all-or-nothing sort of affair. Partially-agile working is also possible, as was the case in the Alexanderplein project.

Directions for future research
There are limitations to this research and potential avenues for future research that come out of it. The first is that the research focused only on Amsterdam practitioners. To address this, we propose conducting similar research in different contexts to test how the findings generalize. Second, while this research found that agile characteristics and practices can work in public planning organizations, how to purposefully implement them is still unclear. A research on this could critically explore the utility of using an agile methodology in planning practice. If some utility exists, one could compare performance of different methodologies. Another route here is to explore the usefulness and feasibility of developing a methodology more tailored to the planning context. If no utility exists, it would be to research working in an agile way without a prescribed methodology. Third, the project stud- ied in this research was largely an agile one. A next step would be to conduct a detailed comparative analysis between one that is and one that is not agile. Finally, one could expand on the practical implications for managers looking to foster collaboration by analyzing the flow of information and work from one actor to another in order to find key players.

Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
Assessment of the way of working in the Bicycle Program of the Municipality of Amsterdam. Table B1 and B2. "I like to give people a lot of responsibility. And I also like to have autonomy…" "The self-organizing teams… we're not really working like that yet." "A program differs from a project in that it focuses on targets instead of results. Therefore, we are flexible, adaptive in the way we deal with projects…" Information drives decisions, not a work hierarchy High level of individual autonomy Embraces conflict and discussion, blends chaos and order "Information is very important. We are used to base our positions on-on information, but also on proven information." "High level of individual autonomy is-that could go wrong in this organization… people setting up their own shop, while you have to think about the common good all the time." "Sometimes you needyou know-to step out a little bit out of your comfort zone in order to advance as a team."   Yes Practitioners in the bicycle program get feedback from a variety of stakeholders, and the "ping if you care" project focuses on getting it from cyclists Simplification-maximize the amount of work not done (only spend time on things that deliver value to customer)

No
There is struggle with this practice partially because it is the public sector, but there could also be more balance with meetings and emails Experimentation, iterative work Yes Highly successful pilot projects are a good example of this Manager is facilitator Partially Some managers act as facilitators Maintain a constant work pace Insufficient data N/A