Collaboration, experimentation, continuous improvement? by Trey Hahn

COLLABORATION, EXPERIMENTATION, CONTINUOUS IMPROVEMENT? A critical exploration of an agile way of working in the planning department context

Trey Hahn University of Amsterdam Master Thesis - June 2019

Photos: Alexanderplein, Amsterdam

Credit from top to bottom: mattresses_of_amsterdam (2016), siebeswart (2016), emmapeijnenburg (2017)

Collaboration, experimentation, continuous improvement? A critical exploration of an agile way of working in the planning department context Master Thesis University of Amsterdam Graduate School of Social Sciences Urban and Regional Planning Dilemmas of urban mobility, and beyond Supervisor: Marco te Brömmelstroet Second Reader: Tuna Tasan-Kok Word Count: 15,150 (main body of paper without figures/tables or footnotes) Trey (Harold) Hahn: #11191457 11 June 2019

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Abstract Urban planners aim to create better living environments for people, and planning departments move towards this goal on a project level. Thus, project execution is key for planning to achieve its purpose. This multi-method research examines the way of working within planning departments and explores how they might transition to working on projects in a way that better serves citizens while using less money and time. It uses the Programma Fiets (Bicycle Program) of the Gemeente Amsterdam (Municipality of Amsterdam) as a case study, and “agile” to operationalize the way of working. It utilizes semi-structured interviews with practitioners along with a literature review, specific analysis of the Alexanderplein intervention, and guided questionnaire sessions as its methods. The research begins by building a holistic understanding of agile in the context of the planning department. It then looks at the gaps between the current way of working in the Municipality of Amsterdam and agile before testing potential solutions to overcome barriers to an agile way of working in practice. At the end, the researcher reflects on limitations and proposes future research.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Thesis structure The thesis is structured as follows: Chapters 1 and 2 include context for the research and its theoretical base. First, an introduction on (problematic) project delivery is given and the question what is a successful project is posed. Then, the theoretical framework of a multi-level perspective on transitions is explained, a research question and sub-questions are derived around it, and an agile way of working is brought in as a way to operationalize the research. Chapters 3, 4, and 5 report on the research itself. Chapter 3 explains the case and the methods chosen to answer the research (sub-)question(s). Chapter 4 presents findings from each method to answer the sub-questions. Chapter 5 brings it all together in a conclusion. Chapter 6 reflects on the research. As a student researcher doing a master thesis, reflection is critical- this section notes limitations and looks into avenues for future research. Finally, Chapter 7 lists references and Chapter 8 contains the appendices.

Acknowledgements This research would not have been possible without the support, guidance and time of many people. First, thank you to all of the practitioners that took the time out of their days for the interviews and survey sessions. It has been a privilege to hear you reflect on your work- it makes me feel inspired and hopeful! Thank you to my thesis supervisor, Marco te Brömmelstroet- you’ve helped me ask questions and be curious: a great environment in which to learn and do a thesis. Thank you to my family for supporting me from abroad, and to my friends here in Amsterdam- it has been really great to have people to talk to and lean on for support during the research process, emotional just as much as academic.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Contents 1. 2.

5. 6.

7. 8.

Abstract… 1 Thesis structure & acknowledgements… 2 Introduction… 4 1.1. What is a successful project?... 5 Theory, research questions, and operationalization… 7 2.1. Research questions and sub-questions… 9 2.2. Agile and urban planning… 11 2.3. Operationalizing agile… 13 Research design… 16 3.1. Case study… 17 3.2. Methods… 18 3.2.1. Literature review… 19 3.2.2. Semi-structured interviews… 21 3.2.3. Assisted process analysis… 24 3.2.4. Guided questionnaire sessions… 28 3.3. Triangulation… 30 Findings… 31 4.1. Sub-question 1… 32 4.1.1. Literature review… 32 4.1.2. Semi-structured interviews… 37 4.1.3. Answering sub-question 1… 38 4.2. Sub-question 2… 38 4.2.1. Assisted process analysis… 38 4.2.2. Semi-structured interviews… 45 4.2.3. Answering sub-question 2… 52 4.3. Sub-question 3… 53 4.3.1. Guided questionnaire sessions… 53 4.3.2. Semi-structured interviews… 56 4.3.3. Answering sub-question 3… 60 Conclusion… 61 Reflection… 64 6.1. Limitations... 65 6.2. Future research... 68 References… 69 Appendices… 81

CHAPTER 1

INTRODUCTION

Images (from top to bottom): Yglesias (2017), “Completion of new metro line unsure as Alderman resigns over cost overruns” (2009), Rosenthal (2017), Meyer (2018), PopeSussman (2016), Cullen (2017), “North-South Amsterdam metro line delayed (again)” (2016)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

1. Introduction “NYC's brand new subway is the most expensive in the world — that's a problem” read the headline of one major media outlet after the long-awaited opening of the first phase of the Second Avenue Subway in New York City (Yglesias, 2017)⁠. Others were not much nicer: one said “It Took a Very, Very Long Time for the Second Avenue Subway to Be a Reality” (Cullen, 2017) and another “The Insanely Expensive Second Avenue Subway Explained” (Pope-Sussman, 2016). New York City waited almost 100 years1 for just the first phase of the project, and paid billions of dollars more than it bargained for: “To put the $4.5 billion cost of Phase 1 in context, when the Second Avenue Subway was first proposed in the late 1920s [originally 3 phases], the estimated price tag of the entire project... works out to about $2.4 billion in 2016 dollars. That's approximately what one mile of Phase 1 cost” (Pope-Sussman, 2016, paragraph 10). Unfortunately, this is not an isolated incident. Phase two of the project is expected to cost even more, with a $6 billion price tag translating into about $2.2 billion/kilometer (Yglesias, 2017), and the estimated costs of another rail project in New York (“East Side Access”) have grown to “$12 billion, or nearly $3.5 billion for each new mile of track” (Rosenthal, 2017, paragraph 5). A project on the neighborhood level in the west side of Manhattan in New York has a local community board member frustrated and confused: “‘They’re going to spend $200 million, and we’re not getting anything,’” (Meyer, 2018, paragraph 3)- despite connecting to the busiest bike path in the country, the project doesn’t include basic protection for people cycling (Meyer, 2018). In Amsterdam, the Noord-Zuidlijn project finally was completed in 2018 at a cost of “more than three times as much as estimated” (Van Leeuwen, 2018, paragraph 4). It was originally scheduled to open in 2005 (“Amsterdam North-South Metro Line Opens 22 July 2018,” 2018). In the academic realm, there is extensive literature on cost overruns in planning projects (Cantarelli, Flyvbjerg, Molin, & Wee, 2010; Flyvbjerg, 2007; Flyvbjerg, Holm, & Buhl, 2003, 2002, 2004), and while the Second Avenue Subway is an extreme case (Nasri, 2013; Plotch, 2015)⁠, challenges in execution of projects are happening everywhere. This raises larger universal questions: What is a successful u rban planning project? How can planning institutions work in order to make sure their projects are successful? 1.1 What is a successful project? In order to investigate these questions, this paper draws on both the fields of project management and urban planning. There is already much literature on the definition of a successful project around both planning infrastructure projects (Flyvbjerg, 2014; Giezen, 2012; Gutenschwager, 1973; Lehtonen, 2014) and project management at large (Alias, Zawawi, Yusof, & Aris, 2014; Attarzadeh & Ow, 2008; Davis, 2014; DeWit, 1988; Hussein, Ahmad, & Zidane, 2015; Müller & Jugdev, 2012; Radujković & Sjekavica, 2017; Shenhar, Levy, & Dvir, 1997). However, despite extensive research there is no consensus. Defining project success is 1

To give perspective on how much time the project took, one writer noted that “the Chicago Cubs have won a World Series and a man has walked on the moon. Fifteen governors and another 15 mayors have come and gone over that time” (Cullen, 2017, paragraph 3)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

“a subject of controversy” (Karami & Olatunji, 2018, p. 122) and “the only agreement seems to be the disagreement on what constitutes [it]” (Prabhakar, 2008, p.3). While it’s clear that success can mean different things to different people (Jugdev & Müller, 2005), there is a well-used theoretical base in the project management field: the iron triangle (Figure 1). The iron triangle measures success through performance according to schedule, cost, and quality of a project (Jha & Iyer, 2007). There has been significant criticism of it (Dimitriou, Ward, & Wright, 2013; Toor & Ogunlana, 2010) for not fully encompassing all of the nuances of project success. This research acknowledges that it is an imperfect theoretical base and that “project success is dependent on one’s perception and perspective” (Ika, 2009, p. 7).

Figure 1: The “iron triangle” of project management (Source: Ebbesen & Hope, 2013, p. 2)

However, the iron triangle has still “become the de-facto method to define and measure project success” (Ebbesen & Hope, 2013, p. 2). It is well-known (Atkinson, 1999; Ika, 2009) and there is power in its simplicity. As this research is not suited to provide a definitive answer to the larger debate on the definition of project success, it will instead adapt the iron triangle to the context of the research. Of its three corners, cost and time are apparent in planning projects and straightforward to measure. The “quality” of a project, however, is not easy to measure in urban planning. There needs to be an indicator more suitable to the planning context, and one that widens the scope of success to be more encompassing (a weakness of the iron triangle). To achieve this, the betterment of life for citizens is a suitable choice. It is a central concept of relevance for urban planning2 and the reason why the profession came to be in the first place (Hall, 1996). This leads to the adapted indicators of success for the purpose of this research: time, money, and better serving citizens. “Better serving citizens” is hard to measure and certainly can vary depending on the context, so this paper takes a descriptive, qualitative approach to it based on what was learned during the research.

As one professional stated reflecting on 60 years of experience in the profession, “the ultimate role of the planner is to help a community become a better place” (Bolan, 2016, p. 285). Other scholars have noted that planning is “an idea made up of concepts and sets of practices, which aspire to change the world for the better” (Campbell, Tait, & Watkins, 2014, p. 47).

CHAPTER 2

THEORY, RESEARCH QUESTIONS, AND OPERATIONALIZATION Image: Geels (2002, p. 1261)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

2. Theory, research questions and operationalization In order for a planning department to complete projects with less time and money spent while better serving citizens, the current way of working has to change. Zooming out, there is a way of understanding transitions on a higher level through a multi-level perspective (MLP) as conceptualized by Geels (2002). There has been much academic use and discussion of this framework (Jørgensen, 2012; Moradi & Vagnoni, 2018; Papachristos, Sofianos, & Adamides, 2013; Smith, Voß, & Grin, 2010; Whitmarsh, 2012)⁠, and extensive elaboration by its author (F.W. Geels, McMeekin, & Pfluger, 2018; Frank W. Geels, 2011, 2012, 2018; Frank W. Geels, Schwanen, Sorrell, Jenkins, & Sovacool, 2018). While it was originally used to understand technological transitions and outcomes, in this research it is applied to the context of transitioning a way of working. There are 3 levels in the MLP: a landscape, regimes, and niches (Figure 2). The landscape comprises the external environmental factors of what is happening overall, and it influences everything else. The regimes operate beneath it. They both influence and are shaped by development of the landscape, and also strongly influence the level below them, niches. Niches are the bottom level of the MLP where new ideas start. Those ideas can come up and potentially influence both the regimes and landscape, while at the same time their own development is highly influenced by what is going on at the top two levels.

Figure 2: Hierarchy of a multi-level perspective on transitions (Source: Geels, 2002, p. 1261)

Many of these new ideas (“novelties” as described by Geels) die out, while others evolve and are incorporated into a regime, and some eventually go on to alter the landscape (Figure 3). It should be noted that change is not easy, and many good ideas will fail to reach the regime level.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 3: Potential paths for novelties (Source: Geels, 2002, p. 1262, via Rip & Kemp, 1996, and Kemp, Rip, & Schot, 2001)

Relating the MLP back to context of the way of working in a planning department, the existing way of working can be thought of as a regime, and the idea for a different way of working lies below in a niche (Figure 4). A goal of this research was to investigate how this different way of working can come up and be adopted by a regime (i.e. planning department) or eventually even alter the larger landscape.

Figure 4: Planning department and way of working in an MLP (Adapted from Geels, 2002, p. 1261)

2.1 Research questions and sub-questions

From the literature review on what a successful urban planning project entails and the MLP on transitions (logic in Figure 5), an overarching question was developed to guide the research: How can planning departments transition to working on projects in a way that uses less money and time while better serving citizens?

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 5: Logic leading to research question

The next step was to operationalize spending less time and money while better serving citizens into a way of working. Due to its extensive literature (Dingsøyr, Nerur, Balijepally, & Moe, 2012) and widespread use in IT and project management fields, “agile”3 was chosen for this. It is a collaborative, iterative way of working that has become a very popular way to execute projects and provide more value for the customer (or in the planning department’s case, the citizen) using less time and money (Dybå & Dingsøyr, 2009; Highsmith, 2002; Pinto & Serrador, 2015). It has become a niche way of working in urban planning and elements of it are present in projects in Seattle (Schmitt, 2019), Singapore (Scruggs, 2018) and Amsterdam (Wagenbuur, 2018). Agile aligns with the indicators of time, cost, and citizens (Cockburn & Highsmith, 2001) in the research question, and is explored more in the following sub-section. Conceptually, an agile way of working has to rise up into the planning department’s regime. While parts of it have been utilized in particular contexts, agile has not been adopted on a widespread level. In order for that to happen, it has to be accessible and relatable to the regime (Figure 6). In a competitive environment where many novelties die out, an idea is not likely to be adopted by a regime without fitting into its context.

Figure 6: Agile and planning department in an MLP (Adapted from Geels, 2002, p. 1261) This research chooses to write agile in sentence case to avoid the over-commercialization and hype that has developed with the term (see Morris (2017) for an elaboration on this thought). Quotations from external sources maintain the original author’s text. 3

Collaboration, experimentation, continuous improvement?

Hahn, 2019

This graphic representation led to logical theoretical steps to answer the research question. The first step was to enable agile to rise into the regime by making it understandable to the planning department. The next step was to better understand the context of the planning regime, before lastly searching for solutions that enable an agile way of working to rise up into it (or even alter the larger landscape). These steps were translated into sub-research questions to structure the research project, and can be found below in Table 1.

Theoretical step

Make agile detectable by wider planning regime

Sub-question How accessible and relatable is agile to planning departments?

Better understand context of planning department

What are gaps between the current way of working and agile in planning departments?

Test potential solutions to have agile rise up into the planning regime

Under what conditions might agile be adopted by planning departments in practice?

Table 1: Theoretical steps & sub-questions (images adapted from Geels, 2002, p. 1261)

2.2

Agile and urban planning

Agile Agile is “the ability to create and respond to change... a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment” (“What is Agile Software Development?,” n.d., paragraph 1). It focuses on delivering a working product, collaborating with customers, valuing individuals and interactions, and responding to change (Beck et al., 2001). It is a more iterative and incremental way of working on projects in comparison to the

Collaboration, experimentation, continuous improvement?

Hahn, 2019

traditional “waterfall” approach (Shawky, 2014). Table 2 describes an agile perspective in detail, and compares it to a traditional view.

Table 2: Difference between traditional and agile way of working (Source: Dybå & Dingsøyr, 2009, p. 7, via Nerur & Balijepally, 2007)

The planning context Given that the goal of planning is to better serve citizens (Bolan, 2016), the potential of agile to facilitate projects that are more aligned with people’s needs using less money and time (Cockburn & Highsmith, 2001) is directly relevant to planning. Despite that relevance, agile has not yet seen widespread adoption in planning. If one conceptualizes an agile way of working as a tool, the case of planning support systems (PSS) (Geertman & Stillwell, 2004; Geertman, Toppen, & Stillwell, 2013; Klosterman & Pettit, 2005)- which are essentially tools to help planners do their complex job better (te Brömmelstroet, 2013)- can provide insight into its adoption. The significant challenges in adoption of PSS by planners (Vonk, Geertman, & Schot, 2005) have led scholars to reflect on why they haven’t been adopted and how they can so that the end goal of improving planning practice can be reached (te Brömmelstroet, 2017). Agile in planning? While it has roots in multiple contexts (Abbas, Gravell, & Wills, 2008; Freedman, 2009; Highsmith, 2002; Rigby, Sutherland, & Takeuchi, 2016a), agile may be best known for its rise in the field of software development.4 Some authors are very excited about it and see potential for it to spread to other industries: “Agile innovation has revolutionized the software industry, which has arguably undergone more rapid and profound change than any other area 4

In 2011, less than 10% of major US federal government IT projects were self-described as “Agile” or “iterative” (Viechnicki & Kelkar, 2017). Yet in 2017 that number rose to an astonishing 80% (Viechnicki & Kelkar, 2017). According to the Project Management Institute, “organizations increasingly embrace agile as a technique for managing projects” (Pulse of the Profession: 9th Global Project Management Survey, 2017).

Collaboration, experimentation, continuous improvement?

Hahn, 2019

of business over the past 30 years. Now it is poised to transform nearly every other function in every industry” (Rigby, Sutherland, & Takeuchi, 2016b, p. 50)⁠. Others are less bullish, arguing that “agile methods are neither panacea nor silver bullet” yet note that more research is needed due to the small sample size of their study (Budzier & Flyvbjerg, 2013, p. 22). Organizations have already started to use an agile approach in multiple fields (Narayanamurthi, 2017), and academic explorations have occurred on the application of agile principles to fields such as education (Andersson & Bendix, 2006; Lang, 2017), construction (Nowotarski & Pasławski, 2016; Streule, Miserini, Bartlomé, Klippel, & García de Soto, 2016), health care (Tolf, Nystrom, Tishelman, Brommels, & Hansson, 2015), and marketing (Poolton, Ismail, Reid, & Arokiam, 2006). In urban planning practice, elements of an agile way of working are already emerging (Schmitt, 2019; Scruggs, 2018; Wagenbuur, 2018). There have also been several conceptual explorations of agile related to planning. Munro (2015)⁠ sees agile through the lens of technology and smart cities, while Jin & Stough (1996) see intelligent transportation systems and technological infrastructure as one part of the larger idea of an agile city. W. W. Clark (2007)⁠ describes agile energy systems and sustainable communities, and Luna, Kruchten, & Moura (2015)⁠ construct a theory of agile governance. Velibeyoglu, Sargin, Bingöl, Saygin, & Yildiz (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, Radhakrishnan, Ashley, Quan, & Zevenbergen, 2018; Radhakrishnan, Pathak, Irvine, & Pathirana, 2017). These are all valuable conceptual contributions around around applying agile to urban planning. However, what remains unanswered by them is how agile translates on an everyday practical level to the context of the planning department. That’s where this research comes in. 2.3 Operationalizing agile There are many different perspectives on agile, and for this research some decisions had to be made up front about how to define it. Lists summarizing the parts of agile relevant to the research (sub-)question(s) were made, which were then used throughout the research. In order to create the lists, literature on what an agile organization is and does, along with barriers to its implementation, was consulted, and a smaller group of main sources were selected. These sources were read in more detail, and key elements on the aforementioned subjects were noted down. The key elements were brought together and consolidated to create three lists: characteristics of an agile organization, practices of an agile organization, and barriers to the adoption of agile. The first two lists relate primarily to sub-question 2 (exploring how the existing planning department works, and then comparing it to agile), while the last one relates to sub-question 3 (understanding conditions- and the barriers needed to be overcome- for agile to be adopted in practice). They lists were used in the semi-structured interviews in the second part of the sessions to get the interviewee thinking about how they relate to their working context, and in the development of the questionnaire.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

It should be noted that the initial list was slightly revised after feedback from the first interviewee about some parts being less clear than others (which made sense- the lists were developed largely from IT and project management literature, so some of the language used may have not been familiar in the planning context). After minor revisions, the lists were made final and used throughout the rest of the research. The final lists on characteristics (Table 3), practices (Table 4), and barriers (Table 5) are below. Characteristic

Sources

Focus on people and interactions over processes and tools

Beck et al. (2001), Cockburn & Highsmith (2001), Highsmith (2002)

Responsive

Cockburn & Highsmith (2001), Dybå & Dingsøyr (2009), Nerur & Balijepally (2007)

Strong focus on satisfying customer

Beck et al. (2001), Nerur, Mahapatra, & Mangalaraj (2005)

Can respond to (and welcomes) change

Beck et al. (2001), Nerur & Balijepally (2007)

Self-organizing teams

Beck et al. (2001), Cockburn & Highsmith (2001), Highsmith (2002), Nerur, Mahapatra, & Mangalaraj (2005)

Flexible, organic organizational form with interchangeable roles

Nerur & Balijepally (2007), Nerur, Mahapatra, & Mangalaraj (2005)

Foster individuals’ skills and encourage creativity while working together as a team

Beck et al. (2001), Cockburn & Highsmith (2001), Highsmith (2002), Nerur, Mahapatra, & Mangalaraj (2005), Nerur & Balijepally (2007)

Information drives decisions, not a work hierarchy

Cockburn & Highsmith (2001), Nerur & Balijepally (2007)

High level of individual autonomy

Dybå & Dingsøyr (2009), Nerur & Balijepally (2007)

Technical excellence

Beck et al. (2001), Highsmith (2002)

Embraces conflict and discussion, blends chaos and order

Highsmith (2002), Nerur & Balijepally (2007)

Table 3: Characteristics of an agile organization

Practice

Sources

Frequent collaboration between roles within project team and with customer

Beck et al. (2001), Cockburn & Highsmith (2001), Highsmith (2002), Nerur, Mahapatra, & Mangalaraj (2005)

Reflection and adjustment at regular intervals

Beck et al. (2001), Highsmith (2002), Nerur & Balijepally (2007), Nerur, Mahapatra, & Mangalaraj (2005)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Early, incremental and continuous delivery of a working product

Beck et al. (2001), Cockburn & Highsmith (2001), Highsmith (2002)

Continuous testing & improvement

Highsmith (2002), Nerur, Mahapatra, & Mangalaraj (2005), Nerur & Balijepally (2007)

Frequent feedback

Nerur, Mahapatra, & Mangalaraj (2005), Highsmith (2002)

Simplification- maximize the amount of work not done (only spend time on things that deliver value to customer)

Beck et al. (2001), Highsmith (2002)

Experimentation, iterative work

Nerur & Balijepally (2007)

Manager is facilitator

Nerur & Balijepally (2007)

Maintain a constant work pace

Beck et al. (2001)

Table 4: Practices of an agile organization

Barrier

Sources

Lack of effective collaboration and teamwork

Chan & Thong (2009), Gandomani & Nafchi (2016), Nerur, Mahapatra, & Mangalaraj (2005)

Organizational culture (resistant to change) Gandomani & Nafchi (2016), Nerur, Mahapatra, & Mangalaraj (2005) Management style

Nerur, Mahapatra, & Mangalaraj (2005)

(New) skills, abilities, knowledge needed

Chan & Thong (2009), Gandomani & Nafchi (2016), Nerur, Mahapatra, & Mangalaraj (2005)

Shared understanding of agile (mindset)

Chan & Thong (2009), Gandomani & Nafchi (2016)

(Detrimental) perceptions of agile methodology

Chan & Thong (2009), Gandomani & Nafchi (2016), Nerur, Mahapatra, & Mangalaraj (2005)

Reward systems & employee career consequences

Chan & Thong (2009), Nerur, Mahapatra, & Mangalaraj (2005)

Organizational structure

Nerur, Mahapatra, & Mangalaraj (2005)

Customer relationships and external conditions

Chan & Thong (2009), Nerur, Mahapatra, & Mangalaraj (2005)

Existing technologies/infrastructure

Nerur, Mahapatra, & Mangalaraj (2005)

Top management support

Chan & Thong (2009)

Table 5: Barriers to the adoption of an agile way of working

CHAPTER 3

RESEARCH DESIGN

Map data by Google

Collaboration, experimentation, continuous improvement?

Hahn, 2019

3. Research design An explorative research with multiple methods was conducted to answer the three sub-questions, which together attempt to answer the overarching research question of how planning departments can work in a way that better serves citizens while reducing the time and money spent on projects. 3.1 Case study In selecting a case study, there are multiple factors to consider; for example: relevance to the research question, research feasibility (practicalities), and relevance for society. Additionally, the research object must be a reasonable size to ensure that the research is feasible. With all this in mind, the Bicycle Program of the Municipality of Amsterdam (“Programma Fiets” in the “Gemeente Amsterdam”, in Dutch) was selected as the planning department case to study the research questions5. The Municipality of Amsterdam is arguably on the cutting edge of planning, and has been described as a “pioneer in technological and social innovations” (Vasarini Lopes, 2018, p. 20). Recent projects such as the redesign of Mr. Visserplein (Wagenbuur, 2018) and the “Ping If you care!” initiative (Mobiel21 & Bike Citizens, 2019) show the city is looking to make infrastructure that works for citizens and is open to new ways of approaching projects (Copenhagenize Design Co., 2014; Gemeente Amsterdam, 2018). Within the municipality, the bicycle program is a crucial part of the city’s larger mobility plans (Gemeente Amsterdam, 2013). It also has larger implications for learning about planning for increased cycling, which is relevant because of the plethora of societal benefits of cycling that recent academic literature has illustrated (Fishman, Schepers, & Kamphuis, 2015; Garrard, Rissel, & Bauman, 2012; Gössling & Choi, 2015; Gotschi, 2011; te Brömmelstroet, Nikolaeva, Glaser, Nicolaisen, & Chan, 2017; Woodcock et al., 2009). Practical access to the research object was also logistically convenient as the researcher resided in Amsterdam. While there are many different levels and types of planning departments in the world, in order to make the scope for this research manageable the aforementioned case has been chosen to study in more detail. What is learned can be used to contemplate larger implications.

The literature review method did not draw specifically on this case

Collaboration, experimentation, continuous improvement? 3.2

Hahn, 2019

Methods

The methods that were used to study the research questions are outlined in Table 6, and below they will be explained in more detail. Figure 7 illustrates the logic followed to arrive at the sub-questions from the main research question, and the methods selected for each sub-question. Sub-question

Data Collection Method

Data

Analysis Method

1. How accessible and Literature review relatable is agile to planning departments?

Academic papers

Literature synthesis matrix

2. What are gaps between the current way of working and agile in planning departments?

Narrative interview. process mapping session, online content search

Narrative interview transcripts, process maps, results from online content search

Thematic analysis on transcripts; together with all 3 sub-methods: “assisted process analysis”

3. Under what conditions might agile be adopted by planning departments in practice?

Guided questionnaire sessions

Questionnaire responses, researcher notes from sessions

Basic analysis from questionnaire responses and sessions

All 3 sub-questions*

Semi-structured interviews

Interview transcripts

Thematic analysis of transcripts

Table 6: Research sub-questions and corresponding methods (*the semi-structured interviews address a targeted part of all 3 sub-questions)

Figure 7: Research logic and methods for each sub-question

Collaboration, experimentation, continuous improvement? 3.2.1

Hahn, 2019

Literature review (sub-question 1)

The first component of the research was a literature review (Torraco, 2005). Sub-question 1 (How accessible and relatable is agile to planning departments?) was broken into two more targeted questions (Figure 8). The literature review targeted the academic perspective, while the semi-structured interviews targeted the practitioners’ perspective.

Figure 8: Sub-question 1 split into two targeted questions

To conduct the literature review on the academic perspective, a literature synthesis matrix (Clark & Buckley, 2017; Webster & Watson, 2002) was used to organize information. The idea of synthesis is distinct from analysis and is an important part of this method. Using a puzzle as a metaphor, Clark & Buckley (2017) explain the difference, “Analysis is taking an already completed puzzle apart, and synthesis is putting individual puzzle pieces together to complete the puzzle” (p. 354). The goal of this part of the literature review was to take ideas from different disciplines and put them together to reach new insights. They are contexts that may appear disparate at first glance, yet upon further examination there are key connections. That is what this review did- it aimed to look beyond the surface conclusions of the authors and conceptualize deeper insights. Selection of literature To start, a very wide informal search was conducted around agile and urban planning. After this wide search, three categories were identified that targeted the sub-question through multiple perspectives and related back to the main research question. They are as follows: ● Planning support systems (PSS): what planning departments need for a tool to be accessible/relatable and successfully integrate into their workflow (note: an agile way of working can be thought of as a PSS that needs to be integrated into practice) ● Agile organizations: characteristics and practices that are present in agile organizations; barriers to adoption of agile ● Translating agile: relatability of agile to urban planning context; how other fields have taken up agile Two pieces of literature from each category (six articles in total) were selected for the synthesis matrix. The individual rationale for each piece is given in Table 7 below.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Category

Source

Rationale6

1. Planning support systems (PSS)

Improving the adoption and use of planning support systems in practice - Vonk G, Geertman S (2008)

Insights from the PSS implementation gap can help inform about the context of the planning department. The authors’ bottleneck categories of diffusion to and in planning organizations and user acceptance are especially relevant lenses.

Transparency, flexibility, simplicity: From buzzwords to strategies for real PSS improvement - te Brömmelstroet M (2012)

This piece is grounded in the PSS implementation gap and gives 3 real-world planning department test cases. Practical insights on transitioning to an agile way of working can be gained from this.

2. Agile organizations

Theoretical Reflections on Agile Development Methodologies - Nerur S, Balijepally V (2007)

This piece elaborates on what an agile approach is and explains how it is developing in disciplines beyond software development.

Acceptance of agile methodologies: A critical review and conceptual framework - Chan F, Thong J (2009)

A survey of literature on the acceptance of agile methodologies and resulting conceptual framework based on a knowledge management perspective inform on barriers to implementing agile in practice.

3. Translating agile

Managing urban water systems with significant adaptation deficits—unified framework for secondary cities: part II—the practice - Pathirana A, Radhakrishnan M, Ashley R, Quan N, Zevenbergen C (2018)

A translation of the principles of the agile manifesto (Beck et al., 2001) to urban adaptation tells us about how relatable agile is to the context of urban planning. The case of the city of Can Tho relates this back to serving citizens.

Implementation of Scrum in the Construction Industry Streule T, Miserini N, Bartlomé O, Klippel M, García de Soto B (2016)

This paper conducts a case study on the use of scrum7, an agile methodology, in a construction company. This offers a lens to reflect on how how accessible agile is to another profession and how it is actually adopted.

Table 7: Literature selected for literature synthesis matrix with rationale

Synthesis The author used three layers of a literature synthesis matrix for his own purposes of understanding and organizing the selected literature. The first layer was on conclusions of the articles related to two relevant themes, the second on who was brought to the table in the article, and the last on what makes the article unique. The two themes were taken from the 6

Relevance to sub-question 1 and/or overarching research question While scrum is a commercial methodology and is often capitalized, this research chooses to write it in sentence case to avoid mystifying it. Quotations from external sources still maintain the original text. 7

Collaboration, experimentation, continuous improvement?

Hahn, 2019

sub-question by breaking it into two broad parts: agile and the context of the planning department. After organizing thoughts on the articles around these themes in the three layers, a final matrix was made to summarize what was learned (see findings section). In line with Van Wee & Banister (2016), added value of this review is in real-world applications (of how to approach planning organizations with agile) and empirical insights (on the nuanced nature of how accessible and relatable the concept is). 3.2.2 Semi-structured interviews (sub-questions 1, 2 & 3) The next component of the research was interviews (Bryman, 2012, chapter 20; Weiss, 1995) of practitioners and thematic analysis (Braun & Clarke, 2006) of the transcripts. According to Guest, Bunce, & Johnson (2006), 6-12 interviews is an ideal saturation point. In this method, 12 semi-structured interviews were conducted with different stakeholders relevant to the way of working in the municipality8. 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, p. 493-494). This method addresses parts of all three sub-questions, and is combined with another method for each sub-question (like described in the literature review section for the academic vs. practitioner perspective). The questions addressed by the interviews are as follows: SubQ1 (targeted): How accessible and relatable is agile to planning departments from the practitioners' perspective? SubQ2: What are gaps between the current way of working and agile in planning departments? SubQ3 (targeted): Which barriers are most relevant to the adoption of agile by planning departments in practice? For sub-questions 1 and 3, the interviews target part of the sub-question, while sub-question 2 is addressed in general. Differences in how each method targets their part of the sub-question are explained their respective sections. This section is written as follows: rationale for selection of participants is given, and then interview design and the approach to analysis are explained. Participant selection In order to gain a rounded understanding of the current way of working in the Bicycle Program of the Municipality of Amsterdam9 and the conditions that would allow agile to be adopted within it, multiple stakeholders that affect the way of working in their own ways were interviewed. Rationale (how the role influences the way of working and/or relates back to the indicators10 of the main research question) is given in Table 8 below.

Of the 12 interviews, 11 were with people in the Municipality of Amsterdam and 1 was with someone from the Vervoerregio Amsterdam, a regional planning organization that works with the municipality. 9 9 of the 12 interviewees were or had at one point been involved with the Bicycle Program of the Municipality of Amsterdam, as had the 1 interviewee from the regional planning organization. The remaining 2 worked in other parts of the municipality. 10 Money, time, and serving citizens 8

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Role

# Interviewees

Rationale

Planner

Creates plans and influences what happens in projects

Program manager

Works at a higher program level, sets example for team of project managers

Project manager

Manages the project level of working, which has implications for time and money spent, and for overall project direction

Urban/traffic designer

Shapes physical design at smaller scale that affects citizens and the time and money spent

Community engagement

Has direct contact with citizens, can get their feedback

Policy

Guides project content at a high level

Total

Table 8: Interviewee roles and rationale for selection

This selection was done with the idea in mind that there are many people that influence how a project is delivered to citizens, not just planners. It should be noted that while participants were categorized into one role for purpose of this research, in practice they sometimes overlapped into multiple roles, so there are limitations to these labels. Interview design The interview sessions began with an introductory section according to best practices practices such as explaining the purpose and giving an overview of the interview, asking for permission to record the audio, and assuring confidentiality and the ability to seek clarification of questions or to decline to answer a question, as identified in Whiting (2008, p. 37). There was a focus on making the interviewee comfortable and communicating that the interview was more of a conversation (and partnership as Weiss (1995) describes) than an interrogation. As stated by Leech (2002, p. 665), “it is possible to be honest without being scary”. The first question asked was intended to “warm up” the interviewees (Zorn, n.d.): “What is your role and responsibilities here?”. From there, an item list (Table 9) guided the rest of the interview. The item list has questions that come from specific items, which fit into larger themes (specifically targeted sub-questions for each section indicated in table). Theme

Items

Questions

Current way Organizational of working characteristics (SubQ2)

About the group you work in at the gemeente: ● What is it called & approx. how many people work in it? ● What different roles exist in it? ● What projects does it work on? ● What is its goal?

What stands out to you the way of working in the group? How important a factor of project success to is…

Details on existing regime & perception of

●

Collaboration, experimentation, continuous improvement?

Hahn, 2019

project success

*To (1) you & (2) your group at gemeente ● money spent on a project? ● time spent on a project? ● serving citizens in a project?

Project level

Can you tell me the story of a recent project you’ve worked on that you thought had a effective (or not) way of working? ● How was the process from start to finish? ● Who were the people involved? ● What was your role? ● What was the project’s goal? ● What was the end output? Reflection on project: ● What do you think was most successful about it? ● What do you think could be improved? ○ How would you suggest improving it?

Agile intro questions (SubQ1)

Exploring one way of working

Agile (SubQ2&3)

Characteristics (SubQ2)

Interviewees identify from lists (1) what is relevant for planning, (2) what reminds them of a project in their workplace

Practices (SQ2)

Storytelling goes from there on each item they bring up

Barriers (SQ3)

● ●

Have you heard of the term “agile” before? What does an “agile” way of working mean to you?

Table 9: Semi-structured interviews item list

After exploring the interviewee’s organization, perceptions of project success, and a project of note, the interview moved into agile. Agile was introduced carefully: a way of working that has been getting increasing attention, but has not yet been extensively applied to the planning context. It was made clear that the way of working may or may not fit into that context- that parts may be more relevant than others, and that this research was talking to practitioners to explore that. Then came the last and longest section: getting practitioners’ thoughts on the agile lists from section 2.3. This part was really open-ended: the interviewees were asked to relate the characteristics, practices, and barriers back to their work. They were encouraged to elaborate on whatever thoughts came to mind- this was where connections between agile and planning were explicitly made. Sometimes comments were positive, sometimes negative, and other times confused. Other best practices were followed during the interviews, such as making markers on relevant items to probe at a later point (different probe types explained by Whiting (2008, p. 38)) and concluding in a professional and friendly manner. In an effort to have consistency across sessions, the researcher created a checklist of items to address during the introduction and conclusion sections. Analysis

Collaboration, experimentation, continuous improvement?

Hahn, 2019

After the interviews, audio was transcribed11 and thematic analysis was performed in line with the phases of Braun & Clarke (2006) (see Figure 9). Transcripts were coded in Atlas.ti, and coding was a combination of inductive and theoretical (Braun & Clarke, 2006). Potential themes were identified from the broad list of codes generated. Due to time constraints, only the first 6 interviews were transcribed12 to reach the beginning of Guest, Bunce, & Johnson’s (2006) 6-12 interview saturation point range.

Figure 9: Phases of thematic analysis (Source: Braun & Clarke, 2006, p. 87)

After generating the initial themes (which begun as semantic, but progressed towards interpretative in certain places) from the transcriptions, the audio of the rest of the interviews13 was listened to and coded. Themes were reviewed and revised, and then all of the data was re-coded before a final determination of themes was made. Relationships to the final two sub-questions are explained in the Answering sub-question 2 and Answering sub-question 3 sections. For this method’s contribution to sub-question 1 (targeted question- How accessible and relatable is agile to planning departments from the practitioners' perspective?), responses from the Exploring one way of working item and general conclusions from the researcher were used. This is described further in section 4.1.2. 3.2.3 Assisted process analysis (sub-question 2) The third component of the research was an “assisted process analysis”- an adaptation of the project management method of business process analysis ⁠(Project Management Institute, 2013; Scottish Qualifications Authority, 2007; Swanson, 2013) to the social science context of this research. This method looked at sub-question 2 (What are gaps between the current way of working and agile in planning departments?) through the lens of a specific project of the Bicycle Program of the Municipality of Amsterdam while the interviews addressed the question more broadly (Figure 10). First, the method will be explained in more detail, and then the case of the specific project analyzed will be introduced.

There were challenges to this that will be explored in the reflection section There were 11 audio recordings in total (1 interviewee preferred not to be recorded)- the transcripts and recordings have been securely stored and can be verified upon request 13 For the one interviewee without a recording, the interviewer’s notes were reviewed 12

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 10: Sub-question 2 addressed through different lenses

The assisted process analysis is a hybrid method that consisted of three parts: an initial search for online content on the project, narrative interviews (Jovchelovitch & Bauer, 2000; Muylaert, Sarubbi Jr, Gallo, Neto, & Reis, 2014), and process mapping (Biazzo, 2002; Damelio, 2011; White & Cicmil, 2016) exercises. The content search was done individually by the researcher, while the latter two were done together during sessions with two project stakeholders- one within the Municipality of Amsterdam and one from outside of it. These different components were used to look at the project from multiple angles. Figure 11 shows how the different parts come together for the analysis.

Figure 11: Assisted process analysis workflow

Online content search The first step of this method was an online search for general information on the project in order to ground the research in its context. This was a surface-level exploration to get a general idea of what happened from publicly-available online information. It was a way to both complement the stakeholder sessions and to prepare for them. The following choices were made beforehand: the researcher chose to look for content related to what happened, the process, and the way of working for the project. Eyes were kept open for articles, social media posts, and any other miscellaneous web pages. What was found was organized and a timeline was made to estimate what happened based on these sources. Narrative interview & process mapping sessions The narrative interview and process mapping parts took place during sessions with two project stakeholders (for their privacy, results have been anonymized). Each component is explained individually first, and then how they are done together is described. 25

Collaboration, experimentation, continuous improvement?

Hahn, 2019

A narrative interview consists of initialization, main narration, and questioning phases (and at the end, concluding “small-talk”) (Jovchelovitch & Bauer, 2000). Essentially, the interviewee is probed with an initial question (in this case prepared as “Can you tell me the story of the Alexanderplein project?”) before proceeding to tell their story. The researcher’s role is to listen and not interfere with the narration. While listening, he or she makes markers on items to probe about later that are related to the research questions (i.e. about the process and way of working in the project). Once the interviewee has told his or her story, the researcher asks follow-up questions from the markers noted down. Narrative interviews allow going “beyond the transmission of information or content, making the experience revealed… they allow the deepening of research” (Muylaert, Sarubbi Jr, Gallo, Neto, & Reis, 2014). Process mapping involves “constructing a model that shows the relationships between the activities, people, data and objects involved in the production of a specified output” (Biazzo, 2002, p. 42). A process map “show[s] clearly what a system does, what controls it, what it acts on, what means it uses to perform its functions and, what it produces” (Biazzo, 2002, p. 46). Its use comes through providing insights on how a given process may be improved (Biazzo, 2002). For this session, a swimlane diagram (Damelio, 2011) (example in Figure 12) was chosen as the type of process map for participants to create because it shows a workflow across different entities or stakeholders, allowing for insight into how the different stakeholders worked together.

Figure 12: Example of a “swimlane” process map diagram (Source: Damelio, 2011, p. 7)

The first half of the session was a narrative interview where the researcher heard about the stakeholders’ personal experiences with the project. After the narrative portion of the session was complete, a brief explanation of process mapping was given. A fact sheet (see appendix) that was prepared beforehand was also given to the to participant to read for a few minutes to give them an idea of what they were going to be doing. Then came the exercise, where the participants mapped their perceived stages of the working process undertaken in the intervention. During the mapping exercise, the researcher was there to answer questions about process mapping, but the participant was given the lead on the exercise and it was them that made the diagram. As this exercise was a bit of an experiment by the researcher, time was left at the end to reflect with the participant on the exercise and its limitations. 26

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Analysis After the sessions, the two narrative interviews were transcribed and thematic analysis was done in line with Braun & Clarke (2006). Like for the analysis of the semi-structured interviews, the researcher generated a broad list of initial codes (coding was partly inductive and partly theoretical) and identified potential themes. Then the initial themes were determined, reviewed and revised. The themes started as semantic but moved towards interpretative during consolidation and revision. Data was reviewed and re-coded before a determination of final themes. Findings from the thematic analysis were combined with what was learned from the process maps and online content search to answer the targeted portion of sub-question 2: What are gaps between the current way of working and agile for a specific planning project? (Sub-)case: Alexanderplein The specific planning project selected for this research was the turning-off and removal of the traffic lights at the Alexanderplein intersection in Amsterdam (Glaser, 2017) (Figure⁠ 13). This was chosen because it was a significant recent project of the Bicycle Program of the Municipality of Amsterdam and because the author was already somewhat familiar with the intervention from involvement in as a student volunteer for research on the intervention in 2016.

Figure 13: Alexanderplein’s location within Amsterdam (Map data by Google)

After consulting many stakeholders, the Municipality of Amsterdam decided to do a pilot project on Alexanderplein where it turned off the traffic lights to see if flow was improved at the intersection. Research studies accompanied this trial to see how it was going, including one of intercept interviews from the University of Amsterdam that studied the human experience of people cycling through before vs. after the intervention. Despite people’s nerves, the trial was declared a success and the intervention was extended for a few months. Eventually, it became permanent and the intersection was fully redesigned. Now, the Alexanderplein intervention is one of several interventions the municipality has taken to improve flow of cyclists.

Collaboration, experimentation, continuous improvement? 3.2.4

Hahn, 2019

Guided questionnaire sessions (sub-question 3)

The fourth and final component of the research was guided questionnaire sessions. It addressed sub-question 3 (Under what conditions might agile be adopted by planning departments in practice?) in a targeted way by testing two concepts as potential solutions to enable an agile way of working in practice. It was also a quantitative complement to the interviews, which focused on barriers in a general and qualitative way (Figure 14).

Figure 14: Different parts of sub-question 3 targeted with guided questionnaire sessions and interviews

The strengths and weaknesses of the two concepts were used as a means to explore the conditions under which agile could work in planning practice. The concepts selected were intended to test, not prescribe, how a potential solution might look like in practice. Due to the exploratory nature of ideas behind in the questionnaire, among other reasons, the researcher accompanied the participants in sessions instead of distributing the questionnaire for them to do remotely. First the content of the questionnaire will be described, and then format of sessions will be explained. Questionnaire design The questionnaire14 (Bryman, 2012, chapter 10) was comprised of 3 sections. The first section asked participants to rate each item from the Barriers to the adoption of an agile way of working list (Table 5 in section 2.3) on scale of 1 (not a barrier) to 5 (major barrier) in the context of a planning department. After the scale questions, participants were given space to explain how they would propose to overcome barriers that received a 5 (major barrier) and to write thoughts they had that could not be expressed in the scale questions. The second and third sections tested potential “solutions” to enable an agile way of working in practice: a pattern language15 for cycling (te Brömmelstroet, Nello-Deakin, Quillien, & Bhattacharya, 2018)⁠ and the bicycle user experience16 concept (Hahn, 2016). The pattern language was selected because of its potential to build a shared understanding between planners and communities of solutions that work for citizens. The bicycle user experience 14

The full questionnaire can be found in the appendix A pattern language is “a grouping of related patterns that work together”, and “an individual pattern… [is] a honed solution or configuration which successfully resolves the conflicting forces in a recurring context... a stable solution” (te Brömmelstroet, Nello-Deakin, Quillien, & Bhattacharya, 2018, p. 5)⁠. 16 While it is called bicycle user experience, its application of human-centered design principles and methods could be translated to any work on public infrastructure 15

Collaboration, experimentation, continuous improvement?

Hahn, 2019

concept was chosen because its human-centered design methods claim to produce infrastructure more in line with people’s needs. These are both in line with this research’s main question, which looks at how to deliver projects that better serve citizens. Each potential solution had its own section, and within each section there were two parts. The first part asked participants to rate each item from the Characteristics of an agile organization (Table 3 in section 2.3) and Practices of an agile organization (Table 4 in section 2.3) lists on how much the solution could enable it in practice. The second part asked how the solution would deal with each item from the Barriers to the adoption of an agile way of working list (Table 5 in section 2.3). Scales of 1 to 5 were used, and a does not apply (N/A) option was also given in case the respondent did not think the agile characteristics or practices connected to the solution (which was to be expected as this was exploratory and the connections between these concepts and agile weren’t known beforehand). At the end of each part, an optional open question was given for participants to record thoughts that were not captured in the rating bubbles (free-text comments are a valuable potential data source, as described by Rich, Chojenta, & Loxton (2013)). In line with best practices for structuring questionnaires (Krosnick & Presser, 2010), the easiest questions were placed at the beginning of the questionnaire (i.e. the barriers list that participants had already addressed qualitatively during the semi-structured interview). Additionally, sections were clearly defined and the structure was communicated at the beginning of the session. Guided sessions The questionnaire was administered in guided sessions for multiple reasons. First, completion of it required a basic understanding of a pattern language and bicycle user experience. Introducing them to the participants in person made it easier to make sure participants had a basic understanding of these. Second, the language around agile had potential to be confusing- both conceptually and in translation. In-person sessions are more flexible and better suited for participants interviewing in their second language (i.e. English instead of Dutch), as mentioned by Barriball & While (1994). Third, as this was on exploratory on a conceptual level, it was not clear how participants would respond to the questions. By being present, the researcher was able to both clarify any of the participants’ doubts that arose and to take notes on their spur of the moment thoughts and reactions to the exercise. The sessions were conducted with three practitioners from inside the Municipality of Amsterdam that had already participated in the semi-structured interview portion of this research. A practical understanding of the planning department was critical here in order to give feedback on where these solutions offer potential and where they fall short in real-world conditions. Thus, participants fell into two categories: planners/designers and senior staff (major decision makers). The planners/designers work on projects on a daily basis, while the senior staff works on a larger organizational level- together, there is a good understanding of the organization and the daily practices. Two of the participants fell into the former category, and one fell into the latter.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

The session was structured as follows. First, an introduction set expectations for the session, showed participants the agenda, and explained that the researcher was present to clarify any doubts that arose. For each section, the sequence was as follows: the topic was introduced, reading material was given, and clarity of the material confirmed with the participant before the completion of the questionnaire section commenced. Reading material was pre-selected by the researcher to be as concise as possible: the Barriers to the adoption of an agile way of working list (Table 5 in section 2.3) for the first section, the most relevant parts of te Brömmelstroet et al. (2018) for pattern language and Hahn (2016) for the bicycle user experience concept (the latter with some additional descriptions added). Analysis Analysis was for this section was quantitative and qualitative. For the quantitative questionnaire results, responses were averaged out and interpreted by the researcher. On the qualitative side, free-text comments from the questionnaire and the researcher’s session notes were interpreted. Additionally, findings from the first section of the questionnaire on general barriers to an agile way of working were used to supplement the interview targeted portion (section 4.3.2) of sub-question 3 (Which barriers are most relevant to the adoption of agile by planning departments in practice?) . 3.3 Triangulation Throughout the design of this research, the concept of triangulation (Carter, Bryant-Lukosius, DiCenso, Blythe, & Neville, 2014; Mathison, 1988; Nolan & Behi, 1995; Thurmond, 2001) was considered. Namely, attempts have been made at methodological triangulation by supplementing the semi-structured interviews with additional methods to go deeper into the sub-questions, and at data triangulation by collecting diverse types of data. Additionally, for the assisted process analysis, sessions were held with stakeholders both inside and outside the Municipality of Amsterdam, and the combination of narrative interviews and process mapping exercises aimed to broaden what was learned. The goal of all of this was to approach the research (sub-)question(s) from multiple angles and reach deeper analysis.

“Focus on people and interactions over process and tools… I think that’s what it’s all about.”

“You have to be in direct contact with the customer at all times. And you have to really take him- take his hand- through the process... And I also think you cannot get their attention early enough...”

CHAPTER 4 “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...”

“Very important, it all comes down to time. Our major concern is to find time windows, time opportunities to realize our projects.” “Information is very important. We are used to base our positions on- on information, but also on proven information.”

“For our group it is kind of important, that there is a good amount of money available... For the bigger projects I would say money is not an issue.”

“Sometimes you need- you knowto step out a little bit out of your comfort zone in order to advance as a team.”

“The customer is very wide… who is the customer? You are a different customer than I am. And people in other branches over there. We all are different customers.”

FINDINGS “Yeah. It’s always important. There’s never enough money for things.”

Quotations from interviewees

“I like to give people a lot of responsibility. And I also like to have autonomy...” 31

Collaboration, experimentation, continuous improvement?

Hahn, 2019

4. Findings 4.1

Sub-question 1: How accessible and relatable is agile to planning departments?

4.1.1 Literature review

The literature review gave an academic perspective on how accessible and relatable agile is to planning departments. First, each source is discussed, and then implications for the (targeted) sub-question are explained. The findings are summarized in Table 10.

Context of planning department

Agile

Vonk & Geertman, 2008

• The PSS implementation gap provides a lot to learn about the context of planning departments • Items have been identified to better fit PSS into practice (see Figure 15) • The authors are participating in (at least advocating for) a discussion with planning department stakeholders and PSS developers about the real issues that exist around making PSS work in practice. • A common way forward that works for all stakeholders is necessary instead of just pushing technology on planning departments

• Agile needs to have a conversation with the planning context, find common interests, and work together to make it happen in practice

Te Brömmelst roet, 2012

• There is a disconnect between the people creating the PSS and the actual receivers/users • Certain traits are important in deploying something in a planning department (i.e. Simplicity, transparency, flexibility, communication) • Improving PSS implementation will be a mutual learning process (also alluded to by Vonk & Geertman (2008)), which necessitates a shift in how the PSS developer acts

• Values behind agile connect well to what is predicted to be well-received by planning departments, but it’s critical that agile’s packaging and implementation mirror these values • It may be good to refocus on the end goal (i.e. organization functioning better) and reframe the conversation if “agile” is perceived as a negative buzzword

Nerur & • The context of the planning department Balijepally, and the “wicked problems” it faces are 2007 linked to the intellectual thought behind agile

• Agile is part of a wider trend of thinking that transcends the software development buzzword • Characteristics of agile link back to theories and metaphors from several different contexts

Chan & Thong, 2009

• Acceptance of an agile methodology rests on knowledge management outcomes, the methodology’s characteristics, and technology related factors (based on their conceptual framework- see Figure 17) • Knowledge management outcomes come from ability, motivation, and

• General organizational barriers to agile can be reflected on for the context of planning departments

Collaboration, experimentation, continuous improvement?

Hahn, 2019

opportunity-related factors • There are underlying assumptions with agile, and agile methodologies may not be suitable for all projects Pathirana • Complex issues faced by planning et al., 2018 departments are similar at a conceptual level to what agile is used for in other contexts

• Agile principles are already implicit in a lot of the discussion around urban adaptation • Agile can be a “practical way to operationalize” a lot of this work

Streule et al., 2016

• Unmodified agile frameworks did transfer out of IT successfully in this case, but adaptation of it was fluid and evolved with time (staying too rigidly in a prescribed framework may defeat the original purpose of agile) • (Parts of) agile may only fit into part of a longer (even linear, in their case) process

• There are nuances in an organizational environment to consider when figuring out if agile will work • With in-house expertise, an agile framework may work in design phase

Table 10: Summary of insights from literature synthesis matrix

The literature of Vonk & Geertman (2008) and te Brömmelstroet (2012) focuses on planning support systems (PSS) and their implementation gap. The case of implementing PSS in practice can be used as a way to understand implementing agile in the context of the planning department. PSS present potential in an age of ever-increasing complexity to improve planning, but there are major gaps to effective implementation of these tools, particularly in their diffusion and user acceptance. Vonk & Geertman (2008) summarize these gaps, which include categories such as “poor fit to planning tasks and users for advanced systems” and “miscommunication between PSS developers, users and experts” (p. 160, Figure 3). They argue that an overall shift from pushing technology on planning departments to working towards combined interests of the PSS developers and planning department stakeholders is needed. Towards the end of their article, they come up with recommendations (Figure 15) on how to overcome the gaps that they originally summarized.

Figure 15: Recommendations to overcome bottlenecks and enhance usage of PSS in spatial planning practice (Source: Vonk & Geertman, 2008, p. 170)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Te Brömmelstroet (2012) builds on the somewhat abstract ideas of previous PSS research and tests concepts in real-life situations. In the workshops in his study, he finds that “the more eager the PSS developer was to learn from the planners and to adapt the product to their demands, the more the planning practitioners were able to use the outcomes for strategy-making” (te Brömmelstroet, 2012, p. 100). He also notes the importance of having a person that made the PSS present to clear up any ambiguities. There is a disconnect between what the tools were intended as and what planning practitioners actually experience. Connecting this to agile, it reveals three important points. First, due to the gap between a tool or concept’s intent and its reception, it would be useful to have an agile “insider” to talk with planning practitioners. Second, this person should be open to learning from the practitioners about their context and how agile can fit into it. Third, a general ongoing discussion between the two parties could be beneficial to have them better understand each other and close a gap between them. In te Brömmelstroet’s (2012) words, “the two domains have to come together in a structured way in which both can open up and learn from each other” (p. 98), and “a mutual learning process between PSS developers and planning actors is key for improving PSS implementation... which requires establishing a structured dialogue” (p. 97). Many key points of te Brömmelstroet’s (2012) article are related to agile principles. For example, he mentions a collaborative spirit, a prototyping process, transparency, and learning, all of which could be related back to agile. He says that in the 30 years prior to his article, main suggestions from PSS research are to “(1) make PSS more transparent and flexible to use, (2) focus on simplicity and (3) improve communication” (p. 97). These align with the list of agile practices in section 2.3. For the first, flexibility is generally an important part of agile, and the second and third suggestions align with the list of practices: Simplification- maximize the amount of work not done (only spend time on things that deliver value to customer) and Frequent collaboration between roles within project team and with customer respectively. While agile is not explicitly mentioned, its characteristics are brought up in the context of the planning department. Nerur & Balijepally (2007) discuss the theoretical bases of agile, and argue that similar intellectual evolutions have occured in architecture and strategic management as the rise of agile in software development. In their article, they draw on urban planner Horst Rittel’s idea of “wicked problems” (Webber & Horst, 1973) in introducing software development as a complex undertaking. They say that wicked problems are unique and evolve, and that as static problem-solving techniques have not been able to adequately deal with them, other approaches have emerged: “emerging practices (such as agile development) question the assumption that change and uncertainty can be controlled through a high degree of formalization” (Nerur & Balijepally, 2007, p. 80). Agile fits into these “evolutionary shifts in design thinking” (Nerur & Balijepally, 2007, p. 81) (Figure 16).

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 16: Evolutionary shifts in design thinking (Source: Nerur & Balijepally, 2007, p. 81)

Thus, this way of thought does not exist in isolation in the IT or software worlds. In fact, “the theoretical assumptions of the emerging practice of design—intertwining thought and action, critical reflection and learning after action, practicality, and satisfying human needs through continuing inquiry—may be traced to Action Learning Theory, Dewey’s pragmatism, and phenomenology” (Nerur & Balijepally, 2007, p. 81). The more iterative approach that utilizes feedback to learn, respond, and ultimately arrive at a better solution (labelled by some as “agile”) transcends software development. Not only may these ideas relate to a more social field, “efforts to understand the theoretical roots… are even more relevant as system domains extend beyond simpler needs (such as technical functionality) to the complex social aspects” (Nerur & Balijepally, 2007, p. 83). On a higher level, “The traditional goal of optimization and control is making way for learning and innovation” (Nerur & Balijepally, 2007, p. 79). Before, it was explained that barriers to PSS in planning departments can be helpful in learning about what needs to happen for agile to be adopted in a planning department. On the other side, general barriers to agile can also be helpful to consider. Chan & Thong (2009) is useful for this- they develop a conceptual framework on the factors that lead to the acceptance of agile methodologies (Figure 17). They find that social characteristics are just as important for organizations to as technology characteristics. Ability, motivation, and opportunity-related factors lead to knowledge management outcomes, and these outcomes - along with characteristics of the agile methodology- lead to acceptance (or not) (Chan & Thong, 2009). Their conceptual framework also explains limitations to the use of agile methodologies, “The various characteristics included in the framework capture certain important underlying assumptions about agile methodologies… If some of these assumptions are not satisfied in a particular project, then the agile methodologies may not be appropriate for that project” (Chan & Thong, 2009, p. 812).

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 17: Factors leading to the acceptance of agile methodologies (Source: Chan & Thong’s (2009) conceptual framework, p. 807)

Pathirana et al. (2018) use Can Tho City in Vietnam as a case to discuss the application of agile principles to urban adaptation. They loosely define agile as “a process where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams, promoted by adaptive planning, evolutionary development, early delivery, continuous improvement, and encouraging rapid and flexible responses to change” (Pathirana et al., 2018, p. 61-62). They argue that three main objectives are applicable to urban adaptation that come from embracing the complexity, uncertainty, and urgency that the field faces: stakeholder involvement, a constantly evolving blueprint (developed through frequent collaboration and communication), and a working product from an early stage. Their literature review finds that agile thinking is actually already present in the field- “recent literature setting out frameworks for adaption has (implicitly) included many of the proposed agile principles for urban adaptation” (Pathirana et al., 2018, p. 62). However, there are two qualifiers to note. First, there are differences between developing cities (their case study) and already developed ones. Second, it could also be argued that “urban adaptation context is far more complicated compared with the original domains the agility principles were borrowed from” (i.e. software development) (Pathirana et al., 2018, p. 71). Despite these limitations, the authors still find that much is transferable to concepts such as sustainability and livability and that urban adaptation needs have the essential components of agile systems. Thus, agile is a “practical way to operationalize” the work (Pathirana et al., 2018, p. 71). Lastly, Streule et al. (2016) explore a specific use case of an agile methodology (scrum) in the design phase of a construction firm’s work. They report a positive reception of the methodology: “all eight interviewed participants would like to continue using Scrum in the Design Process instead of the traditional approach they had used over years of practice” (Streule et al., 2016, p. 275). They state that the application of scrum to the construction

Collaboration, experimentation, continuous improvement?

Hahn, 2019

industry is possible without significant adjustments. Additionally, they believe scrum could be applied to the construction phase and in refurbishment projects, where a daily update could improve project management significantly. However, the authors note the need to be flexible: “our recommendation is not to try to plan every detail of Scrum... but to just do and adapt as needed” (Streule et al., 2016, p. 276) and to not push the methodology in a way that ends up defeating its original purpose. Possessing all the in-house expertise needed for the job is one trait they note as important for the methodology to work. An item of note here is that scrum was just used in the design phase. In the context of the planning department, there may be parts of the project workflow better suited for agile than others. For example, Streule et al.’s (2016) case had to fit into a linear process in accordance with Swiss building standards, yet an agile framework was still partially useful. How accessible and relatable is agile to planning departments from an academic perspective? According to this research, the answer is nuanced. Agile is accessible and relatable to planning departments to a certain extent, but there are qualifiers. It is relevant to the context of the planning department and parts are transferable outside of the IT (information technology) context. However, the exact way in which it should be implemented is still unknown. This research briefly explores this topic, but its main conclusion is that the link between planning departments and agile needs to be studied deeper. There is a theoretical base of agile that is connected to the complex nature of planning (Nerur & Balijepally, 2007), and elements of it are already being used in the realm of urban adaptation and are implicit in that fields’ discussions (Pathirana et al., 2018). One paper (Streule et al., 2016) does suggest that a specific methodology (scrum- a prescriptive way of implementing agile principles that is used primarily in the IT industry) could be directly usable outside of the IT context without modifications. This shows potential that the methodology was successful without modification in the author’s context, but it is also important to note that they state the need to be flexible in implementation and that “constant inspection and adaption of a new Scrum process will evolve with time” (Streule et al., 2016, p. 276). In short, the methodology itself was not the end goal, only a means to an end. This reflects the need to make methodologies useful and not to strictly limit a team to its procedures just for the sake of doing so. A methodology is only one manifestation of the principles, and it is the essence of these principles that is most connected to the context of the planning department. Whatever methodology is used, if any at all, must contribute towards its end goal. 4.1.2 Semi-structured interviews The semi-structured interviews gave practitioner perspectives on how accessible and relatable agile is to planning departments. Out of the 12 interviewees, 11 had heard of agile before and 7 were able to describe part of it, so there is already recognition of the concept within the bicycle program and the larger Municipality of Amsterdam. However, concerns over nuances were brought up several times, and there was some confusion and mixed feelings on how it is implemented in practice. When asked what agile means to her, one practitioner said, “My association is flexible… easy to move to the left or to the right if that’s needed… And also I

Collaboration, experimentation, continuous improvement?

Hahn, 2019

think about a lot of people using words like agile, like scrum-ing, but they don't really know what it means.” Another said, “Yes, it’s like a buzzword- at first it was a new way of working, trying to reduce old ineffective ways of working... trying to reduce red tape and unnecessary rules as much as possible… this is what my interpretation of agile is but… getting more knowledge of agile, I got kind of disappointed”. Some had a more neutral definition: “[agile] is a way of working in which you are flexible in how you go from start to end... so that you also can adjust to circumstances that ask for a different approach” while others couldn’t confidently describe it: “I’ve heard about it but I don’t know any more what it means.” How accessible and relatable is agile to planning departments from the practitioners’ perspective? The mixed responses from the semi-structured interviews reinforce what was found in the academic perspective and further lend to the idea of a nuanced answer to the sub-question. People related to parts of agile more than others, and some were concerned with its implementation (i.e. methodology chosen) while others didn’t bring that up. People had different associations with the term, and at times they described what- as determined by the lists operationalizing agile from section 2.3- could definitely be called an agile way of working, even if it wasn’t explicitly mentioned as such 4.1.3 Answering sub-question 1 In summary, the academic and practitioners’ perspectives illustrate that agile is accessible and can be relatable to the context of the planning department in certain forms, but that it is critical to acknowledge nuances. Agile must be implemented in an agile way, and a shift in how the parties pushing an agile way of working act is needed. This entails more of a mutual learning process (as in the PSS implementation gap explained by te Brömmelstroet (2012)) where the people pushing agile and the planning department employees work together towards the underlying common goal of enabling the organization to function effectively and best serve citizens. As te Brömmelstroet (2012) quotes from Michael Batty, “You should fit a PSS into a planning process, for you cannot fit a planning process into a PSS”. Agile should be fit into the context of the planning department, not the other way around. 4.2 Sub-question 2 What are gaps between the current way of working and agile in planning departments? 4.2.1 Assisted process analysis The findings of this section will be explained in parts: first the online content search, then the narrative interviews and process mapping exercises, and then the targeted version of sub-question 2 will be answered. Online content search The online content search provided a surface-level overview of the Alexanderplein project. Items found included news articles, a blog post, and social media content. The project was also mentioned in an issue of the PLAN Amsterdam magazine (Gemeente Amsterdam, 2018, p. 24-25). A key part of the intervention was that it was a pilot:

Collaboration, experimentation, continuous improvement?

Hahn, 2019

“In ‘pilot projects’ the transport department is shifting from its manual based design (and rules/signs oriented) model to regulate traffic to a more behavior based approach centered around observations. Because of the temporary nature it is possible to shortcut cumbersome institutions and this allows the municipality to experiment with and learn from real world interventions.” (van Beurden, 2016, paragraph 3) The project was an iterative process. It was not clean or easy, there were many steps, and people involved were actually quite nervous (Glaser, 2017). The multiple steps of the process took place over the course of about 2 years and included the pilot and a research study. Furthermore, the impact of the intervention went beyond the utility of the individual project: “In the intervening year, the city has done similar spot treatments and has plans for others to create more space for bicyclists or improve traffic flow and safety. The city also removed traffic lights from the central square, Muntplein. Elsewhere, Glaser says, they’ve experimented with removing protective barriers on some bike lanes to give bicyclists more space, and reduced speed limits to 18 mph (30 kph).” ⁠(Cohen, 2017, paragraph 12) With these ideas spreading to other projects, this appears to be an act of learning for the municipality. There was also an impact beyond Amsterdam- the intervention was mentioned in different contexts in online articles in Rotterdam, the Netherlands (van Vliet, 2016) and Winterthur, Switzerland (“Der nackte Ampelwahnsinn oder sinnvolle Verkehrssteuerung?,” 2018)). Social media showed the project was discussed by people in Mexico (alelealv, 2018) to New Zealand (kentslundberg, 2017), the United Kingdom (RobertWeetman, 2019) and Spain (Bicicleto_ZGZ, 2019). On Twitter, there were posts from an academic (fietsprofessor, 2018), mobility professionals (lennartnout, 2019), and bloggers (modacitylife, 2019), among others. A limitation that should be noted is that content not in English may have been missed. On Instagram, not many posts related to the intervention were found from the beginning of 2016 to now (April 2019). However, progression of the intersection could be seen in users’ photos around the end of 2016. A picture on Nov 15, 2016 had traffic lights in it (mattresses_of_amsterdam, 2016), one on Dec 2, 2016 shows traffic lights on the ground (siebeswart, 2016), and one on Jan 19, 2017 (emmapeijnenburg, 2017) shows the traffic lights have been physically removed (Figure 18).

Figure 18: Instagram photos before, during and after removal of traffic lights (Sources from left to right: mattresses_of_amsterdam, 2016, siebeswart, 2016, emmapeijnenburg, 2017)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Finally, a timeline was created from the information found in the search (Figure 19). The timeline is generally in line with what was learned during the stakeholder sessions.

Figure 19: Timeline of the intervention at Alexanderplein (made only from online content search)

Narrative interviews

“So it was all wrapped up I think in this idea of experimentation” (Interviewee 1) While the content search painted a partial picture, the stakeholder sessions provided much more depth. The first part of these sessions was a narrative interview. What was learned from the interviews is described below, with direct quotations attributed to “Interviewee 1” or “Interviewee 2” to maintain privacy. Some minor differences in their accounts of the project exist, but these were largely logistical (i.e. extension of pilot being two vs. three months); overall, the stories fit together. This section is written as follows: the project will be summarized, a few points of note will be brought up, and then the findings of the thematic analysis will be communicated. The Alexanderplein project occurred in stages, with an initial trial and subsequent re-evaluations and extensions before the intervention became permanent. Decisions were made in consultation with many stakeholders and analysis from research commissioned by the municipality was an important part of them. There were two parts of the research: one more focused on traffic data done by a consultancy, and another more focused on understanding the qualitative impact the intervention had on people using the intersection done by the University of Amsterdam. One interviewee noted that the intervention “was actually more intended as a research project than a measure in itself” (Interviewee 2), but that eventually it became its own project. 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 Alexanderplein arose inside the bicycle program in this context. While it was originally intended to be a low-cost measure, it ended up stretching out because so many stakeholders had to be consulted (Interviewee 2).

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Another item of note was that the internal team working on the project was very hands-on and willing to take risks. The project may not have happened if that wasn’t the case. Additionally, most of the work for the team came before and during the intervention. After the 3 month extension, another staff member working on traffic- one that really liked the intervention once seeing its success- ended up taking over the project. 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. One said “I think it helped to legitimize the change” (Interviewee 1), while the other remembered thinking “if we’re going to do this we have to do it based on a good analysis” (Interviewee 2). The detailed analysis showed that there was low motor-vehicle traffic at the intersection (quantitative), that the intervention could be done safely (quantitative), and that people generally preferred the new situation (qualitative). Additionally, the fact that internal traffic specialists did analysis of the video taken of the intersection and found the intervention successful led to internal approval for the project. They even found footage of two kids meeting on the way to school- with the traffic lights off, they could meet up smoothly and ride together without having to stop and wait for the lights. The insights from the qualitative intercept interviews also provided insights for staff that went beyond the Alexanderplein project, such as learning about stress and discomfort that cyclists experience. This leads to the findings of the thematic analysis. Three main themes from the narrative interviews were found: an iterative project strategy, legitimization through analysis (as mentioned above), and maneuvering stakeholders and organization( s). Within these main themes there were sub-themes (visible in the thematic map shown in Figure 20 below).

Figure 20: Thematic map from narrative interviews

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

Collaboration, experimentation, continuous improvement?

Hahn, 2019

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 analysis showed that the themes are very tightly connected, and there are several quotations that exemplify this. For example, “By doing it- like first of all having a good analysis, doing it temporarily in the first instance and then having good measurements about what- what’s actually happening in both datasets-the visual analysis but also the qualitative analysis by interviewing people. That helped us enormously to get it passed through” (Interviewee 2). In this one quotation, every theme is touched on: the interviewee connects the initially temporary nature of the project (iterative project strategy) and the datasets showing what’s actually happening (legitimization through analysis) with getting the project passed through (maneuvering stakeholders and organization) . Some of the connections were more implicit, such as, “something like 80% at baseline- 80% of respondents said that they strongly disliked the intersection and then during the intervention it was something like 50% or something who disliked the intersection. So it’d be curious to see what that is now. And I remember them using that particular statistic” (Interviewee 1). On face value, this is using analysis to legitimize the intervention. However, thinking deeper one can see that an iterative project strategy (the idea of a trial to be evaluated) made this analysis possible in the first place. So, not only did the analysis enable an iterative project strategy, but also the other way around: the iterative project strategy enabled the analysis. Then, the interviewee connects this to public acceptance and maneuvering organizations, “And then I think once they figured out that it was, you know, a generally accepted measure- the turning the traffic lights off- then it went into this redesign proposal phase” (Interviewee 1). The analysis legitimizes the intervention (and people get used to it with time), allowing the project to move into the next stage. Process mapping

“Everyone was very nervous- you know- they were just biting their nails, waiting for chaos to ensue. And that didn’t happen, obviously.” (Interviewee 1) The second part of the sessions dived deeper into the different stakeholders that had to be dealt with in this project. As the above quotation suggests, there was tension and worry- turning off the traffic lights was not a simple process. The process mapping exercise- where the participant visually drew out what (from their point of view) were the important parts of the Alexanderplein project- enabled the research to begin to unpack this process. Each of the two interviewees approached the exercise slightly differently, with varied choices in drawing the diagram and the stakeholder categories (entities) through which the process

Collaboration, experimentation, continuous improvement?

Hahn, 2019

moved. The entities ranged from the customer (of which there were many- cyclists riding through the intersection, pedestrians, and people in the immediate vicinity of the intersection) to the city council organization, to the external consultants, to even the world and society at large. The process maps drawn can be seen in Figure 21.

Figure 21: Process maps

The maps show a complex process with multiple rounds of analysis and reinforce the idea of an iterative project. They also show the project move through multiple entities (especially through the municipality), and the connections between the different entities show the importance of being able to work together in delivering the project. 43

Collaboration, experimentation, continuous improvement?

Hahn, 2019

What are gaps between the current way of working and agile for a specific planning project? The Alexanderplein project had several agile characteristics and practices. However, it did not cover the entirety of the agile lists. The ones most evident in the project from what was learned during this research are broken down in Tables 11 and 12. Agile characteristic

Alexanderplein project

Focus on people and interactions over processes and tools

Focusing on getting many different people on board was a necessity; qualitative research (interviews) also focused on people’s experience in the intersection

Responsive

Strong focus on satisfying customer

Many different types of customers had to be satisfied in the project

Can respond to (and welcomes) change

Process did not easily welcome change, but people working inside it did

Self-organizing teams

Flexible, organic organizational form with interchangeable roles

Bicycle program worked across different departments, but overall municipal structure did not appear flexible

Foster individuals’ skills and encourage creativity while working together as a team

Information drives decisions, not a work hierarchy

Project iterations were public experiments; results and analysis drove decisions

High level of individual autonomy

Technical excellence

The new configuration is an improvement by several measures, as demonstrated by the analysis

Embraces conflict and discussion, blends chaos and order

Stakeholder and public discussions; moving through conflict and people was necessary for project to happen

Table 11: How the Alexanderplein project measures up to agile characteristics (green = yes, orange = somewhat, red = no, blank = no clear conclusion could be made)

Agile practice

Alexanderplein project

Frequent collaboration between roles within project team and with customer

Collaboration with (getting consent from) different stakeholders was necessary to move forward with the project

Reflection and adjustment at regular intervals

Early, incremental and continuous delivery of a working product

Intersection remained functional throughout changes, yet delivery of changes was not continuous

Continuous testing & improvement

Different improvements were made in multiple phases according to what was learned

Frequent feedback

Research and analysis during the trial period gave feedback to decision-makers to inform whether to continue with intervention

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Simplification- maximize the amount of work not done (only spend time on things that deliver value to customer)

Extensive work had to be done to execute a small action (flipping the switch); however, steps within the process may have done this simplification better

Experimentation, iterative work

Entire project was originally conceived as an experiment; process was iterative

Manager is facilitator

Maintain a constant work pace

Table 12: How the Alexanderplein project measures up to agile practices (green = yes, orange = somewhat, red = no, blank = no clear conclusion could be made)

Could it have been more agile? Would doing so have improved the project outcome and better served citizens while using less time and money? Yes and potentially- but the second answer is not fully clear from this research. What is clear is that what was done has been seen as a success by many. Citizens now have infrastructure coordinated to their needs, and while the project did take quite a bit of time, infrastructural changes needed for the intervention appear comparatively small to what could have been done. This shows that agile working doesn’t have to be an all-or-nothing sort of affair, and there appears to be benefits from being only partially agile. This also connects to the findings of section 4.1 that moving forward towards common goals is more important than forcing adherence to something. In the case of Alexanderplein, feedback from the analysis, informed iteration of street design, and learning about cyclists’ experiences on the street all happened. And it was done with a physical intervention in the public realm. 4.2.2 Semi-structured interviews As the Alexanderplein intervention was only one project of the Municipality of Amsterdam, the semi-structured interviews zoom out to look at the municipality in general. In reporting back the findings of these interviews, it is important not to lose the qualitative richness of the conversations. Thus, the first part of this section presents collections of direct quotations from interviews on the main relevant topics (Tables 13-17). The quotations come only from interviews 1-6 (the ones that were transcribed). The second part of the section goes into the thematic analysis.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Project success factors

Money

Time

Serving citizens

"For our group it is kind of important, that there is a good amount of money available... For the bigger projects I would say money is not an issue." "Yeah. It’s always important. There’s never enough money for things." "It should argue very well why it’s necessary. And you have to... well you have to research just to find out how much will it cost, where it does come from, what does it give?" "Not important, no." "I would always relate that to the results... and also to the goals that you have with your projects." "That’s important I think, and that has to do with the systematics that are currently in use. There is like this hard boundary between- I think below 50,000 euros you can do basically anything you want; you have to, you know, account for what you are doing and to say what your goals are and what your activities are but no one’s really, really paying very close attention to what you’re doing. But if you’re above that... they will start to look really, really close..."

"Again I think there’s a distinct difference between the projects." "Ah, that is kind of important, yeah." "It depends on the project and it’s always a problem…But it’s always difficult because you never know what happens...it can sometimes it can change, it can evolve as well, sometimes it’s ok." "Very important, it all comes down to time. Our major concern is to find time windows, time opportunities to realize our projects." "I don't think that people in general are using their time as effectively as they can possibly do it. So there is a lot of time that’s going to all these bilateral meetings… and putting programs together and aligning… if we were able to spend more of our time on projects, that would speed the projects up." "Well, less important unless the… like the deputy mayor really wants this to be done right now, then it’s very important. So the higher it is in the political agenda, the more important the factor of time is."

"Ummm, that’s a difficult one... if I listen to the people locally, I’m probably not listening. If I listen to the people more broad in Amsterdam, we are doing the right thing. So that’s the nuance..." "I think very important, yeah." "It is important because if citizens don’t like you have to- don’t like what you do they don’t do it. Especially- especially cyclists don’t do what you want if you don’t- if they don’t want to do it. It’s quite difficult. And sometimes it is… and not all cyclists are the same. All citizens are not the same..." "A lot of the operation is done by project managers and they have, they have the direct contact points with citizens..." "More and more inhabitants of Amsterdam are afraid that the hordes of bicycles will make their neighborhoods less liveable... So new bicycle infrastructure is not seen in general as an improvement for neighborhoods, but as a threat." "This time, with this city management, like the mayor and the alderman right now- it’s very important."

Table 13: Project success factors quotations

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile characteristics

Focus on people and interactions over processes and tools

Responsive

Strong focus on satisfying customer

"I would say the soft characteristics... focus on people… flexible… would be important for urban planning but be important for any organisation I think." "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?’" "Focus on people and interactions over process and tools… I think that’s what it’s all about. You need to have the overview from each particular person or municipal stakeholder... You need to know what’s on their mind, what’s in it for them. And then you can make it work, you can create that communal goal."

"Responsive… I hope we are." "Responsive or that you can respond and are open to change, that's an important thing." "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..."

"The customer is very wide… who is the customer? You are a different customer than I am. And people in other branches over there. We all are different customers." "What we as a bicycle program are really focusing on is satisfying customers because the goals of the program are mainly focused on grades that our customers, the cyclists, are giving us..." "I think that's an important one which is really difficult to do I think because what I see is that what people tend to do to make it easier is to think for the customer instead of really asking the customer what he wants or what she wants."

Can respond to (and welcomes) change

Self-organizing teams

Flexible, organic organizational form with interchangeable roles

"I think that’s very good. How do you communicate the change? Because change is very scary..." "You have to be responsive if you choose to be open to collaboration. You can also choose not to do that, then it’s maybe easier but it’s not the best way to work I think, especially in this large an organization. And in urban planning also specifically it's really important to know what others are doing and to be able to respond to that." “It's really important also from a personal point of view... how you personally deal with the moment to accept ‘ok I put a lot of effort to achieve something and it's not working; I have to let it go’.”

"I like to give people a lot of responsibility. And I also like to have autonomy..." "It’s also self-organizing teams, and in that case you need to be responsive to what they want to give in, bring in. If you’re gonna be too top-down about it, they will walk away." "The self organizing teams… we’re not really working like that yet." "Yeah self-organizing teams would be hard."

"It's also not really happening since everyone is doing their thing. Their management thing or their technical thing or their designing thing. But in these workshops… it’s also people who are not designers can come up with great ideas… it also depends on, I think a lot depends on the general manager..." "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..." "The system works with not fluid but the opposite of fluid roles. So you are a senior policy maker in this and this field and you can never be something else."

Table 14: Agile characteristics quotations, part 1

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile characteristics

Foster individuals’ skills and Information drives decisions, not encourage creativity while a work hierarchy working together as a team

High level of individual autonomy

"Well I think it’s important… this one- foster individual skills and etcetera, for our organization..."

"We work in teams. I- of course I have a manager because it’s necessary for other things. [laughs] But I have only one manager… Well it’s hierarchic but not really very strong and we are left very- we are working free. We can organize our own work...” “Information is very important. We are used to base our positions on- on information, but also on proven information." “I think it's an unsaid, an unspoken philosophy within our team that it’s not based on a strong hierarchy… Yes we focus on information, but at the same time interesting is that in the way we prioritize our work, in the way we make transparent decisions..."

"I don’t necessarily agree with that. That’s what you should try to avoid in this whole case... Autonomy is fine once you define the actions or things each has to do because it is not only talking and coming to proposals but someone has to work out those proposals. It’s fine to do that individually but it’s not a solo thing." "High level of individual autonomy is- that could go wrong in this organization… like people setting up their own shop, while you have to think about the common good all the time." "I like to have a lot of autonomy so that's what I think is really motivating for other people as well..."

Technical excellence

Embraces conflict and discussion, blends chaos and order

"A little bit. That’s what we try to do with each of those work plans. Is to make them technical, to go into the depth of the topic." "Infrastructural things should also be very important, that’s right... But you don’t need it everywhere..."

"Sometimes you need- you know- to step out a little bit out of your comfort zone in order to advance as a team." "A lot of discussion is also very necessary because if you don’t discuss and play the role of the devil... you have to do that because otherwise you just go in one direction..."

Table 15: Agile characteristics quotations, part 2

"I think it's really important to have the conversation to speak about different opinions and have discussion but... you know you have to be careful because if you are too convincing you can get people get angry and they won't work with you." "That’s also very good. That’s what I try to do with all these different…. people who give the assignment in the end."

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile practices

Frequent collaboration between roles within project team and with customer

Reflection and adjustment at regular intervals

Early, incremental and continuous delivery of a working product

"Involving the customer on a regular basis is I think a really good thing." "We don’t work with customers but in this case you can say that each of the directors are a little bit a customer." "One of the most essential parts of a program is that it all fits together- if one my colleagues works on some measures and I work on others there is usually a connection in one way or another... we cannot work in the general interest of the Amsterdam fietser if we do not relate to each other..." “You have to be in direct contact with the customer at all times. And you have to really take him- take his hand- through the process... And I also think you cannot get their attention early enough...” “I believe that you want ownership over a project or a process also with the customer. You create ownership by- you know… looking for a word again… asking him as early as possible in the process to join you, and to make it a joined effort..."

“If you start with a project you have to think what you want, what was happening before, what’s- make an analysis of course… Are we solving the problems or are we solving… we have to reflect on what we do and base our work on the analysis of things we want to change...” “Not only going forward but also ask other people- especially people not from your own team but from the other disciplines, because yeah well you’re thinking in cycling, how it works but when people can from other disciplines say ‘well did you think about this?’"

“You’re not waiting too long with only talk and talk and talk... That’s a very good one, yeah. And then it can actually be in every meeting it can be. It doesn’t have to just be feedback from other designers or… everyone comes, everyone can have good feedback, everyone has cycled, and everyone is a pedestrian, it doesn’t really matter what your role is in the process. Ehmm, alright it’s a little related to reflection at regular intervals, of course.”

Table 16: Agile practices quotations, part 1

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile practices

Frequent feedback

Simplification- maximize Experimentation, iterative work the amount of work not done (only spend time on things that deliver value to customer)

"I’m not sure what frequent feedback is about. Do you give feedback to the customer... because with “ping” it is a feedback tool so it’s all about feedback. And we give feedback about the feedback they give us." "Frequent feedback is not something that you can… That’s part of the culture between the people you work with and depends heavily on trust and feeling safe and what you feel like yourself, how you feel about your colleagues. That's really a deep belief- I believe that people, coworkers, a team can only be a team if you are very clear on how you feel about your work- what makes you happy and what makes you unhappy?"

“I think what it appears to be is that you want to be highly effective in what you do, so make it as simple as possible... So it is only putting your time in things that add value or are effective to reach the goal of the customer..." "The simplification, that you only spend time on things that deliver value to customers is really, really important. That’s what I meant when I said that I have some time… a lot of my time is not spent in a very effective way."

“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… we also want to have a conversation with the city, with the cyclists themselves, to help us to make our approach better, to ask them if we have the right tone of voice or if we should change it. We want to invite them to give us feedback in any way.” “We do a lot of pilots, but that’s...that’s more the work of the people that work on the long-term bicycle plan… executing the measures, yeah. But just to find out- does it work on the street?” “And we had to change rules when we did that, because in the Netherlands we have all kind of rules for measures of crossings… And we changed that.”

Manager is facilitator

"My eyes are just going to this ‘manager is facilitator’ [laughs]... That would be very nice. We just tell the manager what to do. [laughs] And they’ve got to do it. Doesn’t always work like that. But sometimes the manager is also very… not only managing but also has very much an opinion as well. Which is not bad or good, it’s just like that.” “We got more and more managers... sometimes you’ll have meeting and it’s only managers, not the people who are redesigning and it’s sometimes hard talks.”

"And more managers means more mail, more questions from them, more typing instead of… it’s also work of course, but it’s... Yeah, that is a little bit simplification maybe." “That’s also not the case right now... What you see is that the managers have got a lot of responsibilities, but they do not cater for the needs that you have...”

“You have to have the ok of manager number 1 and then the approval of manager number 2 and that’s a long time, so it would have been very helpful for me if my manager would have said ‘what do you need and I will try to supply it to you as quickly as possible’. It’s not that I have a problem with this manager because he’s a really nice guy." "Manager is a facilitator- that’s… that’s an expression for us I think."

Table 17: Agile practices quotations, part 2 (note: there were no significant quotations from transcripts on Continuous testing & improvement and Maintain a constant work pace)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Thematic analysis Four main themes were found in the semi-structured interviews. The first two 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 Figure 22 below.

Figure 22: Thematic map for semi-structured interviews

During the analysis, it also became clear that the agile characteristics and practices are connected to each other. For example, one interviewee makes a connection between early and incremental delivery, feedback and reflection, “This early, incremental and continuous delivery of a working product means that you always have your product but you are always trying to improve it all the time? You’re not waiting too long with only talk and talk and talk... That’s a very good one, yeah. And then it can actually be in every meeting it can be. It doesn’t 51

Collaboration, experimentation, continuous improvement?

Hahn, 2019

have to just be feedback from other designers or… everyone comes, everyone can have good feedback, everyone has cycled, and everyone is a pedestrian, it doesn’t really matter what your role is in the process. Ehmm, alright it’s a little related to reflection at regular intervals, of course”. Additionally, when practitioners told their personal stories, they showed how the agile characteristics and practices related directly to what they face at work. 4.2.3 Answering sub-question 2 In the Alexanderplein intervention and in general, the Bicycle Program of the Municipality of Amsterdam is already working in a partially agile way. 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 current way of working and agile, namely: responding to and welcoming change, early, incremental and continuous delivery of a working product, and simplification (maximizing the amount of work not done). Tables 18 and 19 break down this down fully for each characteristic and practice using the lists from section 2.3. Agile characteristic

Bicycle Program of the Municipality of Amsterdam

Focus on people and interactions over processes and tools

This consistently resonated with interviewees, and overall the municipality appears to do it

Responsive

Some teams within the larger organization are responsive

Strong focus on satisfying customer

The big question is: who is the customer? Interviewees had multiple perspectives on this- the municipality is serving a variety of parties. Parts of the organization focused on this more than others.

Can respond to (and welcomes) change

While some individuals and small working groups do this, the municipality appears to struggle with this as an organization

Self-organizing teams

Self-organizing teams happen in some groups

Flexible, organic organizational form with interchangeable roles

Workshops enable temporarily more fluid roles, and within small teams working is more flexible than at a higher level of the organization

Foster individuals’ skills and encourage creativity while working together as a team

There is a strong team focus in the bicycle program that seems to work well and allow creative ideas

Information drives decisions, not a work hierarchy

A focus on the importance of information was brought up frequently in the interviews

High level of individual autonomy

Despite variations by manager and employee (not all interviewees supported this), there appears to be a high level of individual autonomy

Technical excellence

On infrastructure projects, the technical quality from the bicycle program is high (but only when needed- in many cases in planning it doesn’t seem to be a focal point of working)

Embraces conflict and discussion, blends chaos and order

Overall, the bicycle program embraces discussion, although there is some variation at the individual level

Table 18: How the Bicycle Program of the Municipality of Amsterdam measures up to agile characteristics (green = yes, orange = somewhat, red = no)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile practice

Bicycle Program of the Municipality of Amsterdam

Frequent collaboration between roles within project team and with customer

Collaboration within the project team, the larger organization, and with citizens is a necessity to move forward in the municipality’s context, and it is doing it

Reflection and adjustment at regular intervals

Practitioners from the interviews highly valued reflection

Early, incremental and continuous delivery of a working product

Some ideas are presented for early feedback, but delivery is not incremental and continuous

Continuous testing & improvement

Despite its leading position on cycling worldwide, the Bicycle Program of the Municipality of Amsterdam continues to test new ideas and look for ways to improve cycling experience

Frequent feedback

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)

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

Highly successful pilot projects are a good example of this

Manager is facilitator

Some managers act as facilitators

Maintain a constant work pace

Table 19: How the Bicycle Program of the Municipality of Amsterdam measures up to agile practices (green = yes, orange = somewhat, red = no, blank = no clear conclusion could be made)

4.3 Sub-question 3

Under what conditions might agile be adopted by planning departments in practice? 4.3.1 Guided questionnaire sessions There are two main components of the findings from this section: quantitative results from the questionnaire and qualitative results from the free-text comments in the questionnaire and the researcher’s notes from the sessions. First the quantitative findings will be presented, and then the qualitative findings. It should be noted that this was the smallest method of this research and was intended only to test potential solutions. There are limitations to the sample size and the answers that were given, and further research to build on this is suggested in the reflection section (6.2). Overall, respondents rated the potential solutions positively in terms of enabling planning departments to work in an agile way, and even more highly in their ability to overcome common barriers (Figure 11 from section 2.3) to the adoption of agile. Out of the 62 total rated items (31 for each potential solution), 56 of the rating averages were positive (over 3 on a scale of 1 = strongly disagree to 5 = strongly agree). The full results are shown below in Figure 23 for pattern language and Figure 24 for bicycle user experience.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 23: Questionnaire findings on pattern language

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 24: Questionnaire findings on bicycle user experience

Both concepts seem to have the most potential in enabling planning departments to Focus on people and interactions over processes and tools. They both received a 5 average rating without any “Does not apply (N/A)” responses. Pattern language also had an average rating of 5 for Early, incremental and continuous delivery of a working product and Managers being facilitators, although these each had one N/A response. One out of three respondents saying it does not apply to the concept may be a red flag. The potential solutions do not address all of the agile characteristics and practices equally. A constant work pace, for example, s cored low for both solutions (with one N/A response for each). N/A responses and mid-range scores for several items show that neither solution is close to being a “silver bullet”, or perfect remedy, for making planning departments agile. For the overcoming barriers items, all average scores were above 3 and there were no N/A responses. The bicycle user experience’s ability to overcome the Customer relationships and external conditions (5) and (New) skills, abilities, knowledge needed ( 4.67) barriers were rated 55

Collaboration, experimentation, continuous improvement?

Hahn, 2019

highest, and a pattern language’s ability to overcome Shared understanding of agile (mindset) (4.5) was rated highly as well. Conversely, the ability to overcome a Lack of effective collaboration and teamwork was rated low for both. This lends to the idea that the solutions are better suited to solve some problems related to agile working more than others. The free-text comments and notes taken during the session captured thoughts and reflections that the quantitative part could not. First, it was learned that the Bicycle Program of the Municipality of Amsterdam is already using working methods similar to the bicycle user experience and that management has ambitions to implement pattern language in working with citizens. Second, more insights around the solutions were learned. For example, one participant noted that there was not much organizational time devoted to doing studying of people as is necessary for the bicycle user experience, and that a citizen-centered design process should be careful not to be limited to the people that show up frequently during participation (it needs to reflect a larger group of people). Another said that the everyday person may not advocate for removal of traffic lights, and that the Fietsersbond (cyclists’ union) was originally against the “Fietsstraat” on Sarphatistraat, which was another successful pilot project that turned permanent. Finally, there was valuable feedback the questionnaire method itself (discussed in reflection section). How do two potential solutions enable or fail to enable an agile way of working in practice? The guided questionnaire sessions show that neither of the two concepts is a “silver bullet” to enable agile in practice. Both pattern language and bicycle user experience have potential to enable planning departments to focus on people and interactions over processes and tools, but with other characteristics and practices it is less clear, especially for fostering a constant work pace. The concepts are perceived to be able to successfully overcome common barriers to agile implementation, and they warrant additional study. 4.3.2 Semi-structured interviews As was done in sub-question 2, the interview findings will be reported back in two parts. First, direct quotations on barriers to the adoption of agile will be presented in Tables 20-21 (quotations come only from interviews 1-6 (the ones that were transcribed)). Then, findings related to barriers to the adoption of agile from the thematic analysis are explained.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile barriers

Lack of effective collaboration and teamwork

Organizational culture (resistant to change)

Management style

"If people only work in their own project, and doesn’t search for other people… A design team from “project x” picks up or is trying to get their information about everything bike-related soon. And use that more as a stronger input, or a stronger motivation..." "I have never had it- can’t remember... Yeah I’m really lucky..."

"Most of the time change is causing worry or fear. Fear of losing a position or uncertainty and that's a really important area I think to any change." "I don’t think that’s happening so much, the organizational culture. More and more people are finding each other… every year it’s getting better finding each other. Faster, better, smoother." "A lot of people tend to stick to what they’re used to and it’s really busy and we have a lot to do, this is our main focus, we improve bicycle infrastructure- so please, I don’t have time to move to a new way of organizing my work."

"It has more to do with playing, or trying to play the management game or whatever… who’s gonna pay this or who’s gonna pay that, not looking at what the end situation is gonna be, it’s more about the game, who’s gonna win or lose this thing about, for example this tram pole I mentioned earlier... I don’t really like it..." “Management style can make or break your project.” “Of course it's important, because if- as I told you it’s very nice if we can do our work very independent from the manager... You need one who leaves you free in your own capacities. He trusts us, they trust us.”

(New) skills, abilities, knowledge needed

Shared understanding of agile (mindset)

"We don't have an agile guru on our [team]. I think you need really need some skills. Actually I think the best way to learn is to be dropped in an IT environment and just experience how it works. Because if you give me this list and I think ‘well let's try and make this organisation agile’, I don't think it's gonna work." "You just need to be open to new opportunities."

"A shared mindset is a really important thing… the really strange thing about this Verkeer en Openbare Ruimte department is that they really… there are 2 worlds- there is the world of policy making and there’s the world of doing things... I thought it was really negative and almost offensive but he really meant it in a true way- ‘I’m about policy, I’m not about the execution’, so that doesn’t help.”

"It’s also not always age based, it’s not people who are almost going with their pension, who are almost 65 are not gonna be, are not able to be agile anymore. That’s not really a thing."

Table 20: Barriers to the adoption of agile quotations, part 1 (note: there were no significant quotations from transcripts on (Detrimental) perceptions of agile methodology)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Agile barriers

Reward systems & employee career consequences

Organizational structure

Top management support

"Should that be a motivation to work or not work more or less agile? I’m not sure. I’m not sure actually, if agile is a new term? I haven’t been... Shouldn’t [agile] just be your work… to work like this?"

"Organizational structure can be also a problem... We have a large… a large gemeente. The municipality is very large and our own department… well it's quite easy to find the right colleagues… you have to have help from your colleagues- and they do, they help you if you need people." "You’ve got all these different societal transitions, like the energy transition, the mobility transition, circular economy and they are- it’s more and more complex- and the way that the management structure is right now, is… they don’t fit to the challenges we are- it doesn’t fit to the challenges we are facing right now."

"If top management thinks we should work in a certain way I think it's important but it is also not enough to just push it through." "Sometimes, a lot of times the top management comes in to when there’s troubles." "In this case it’s not… the product is not politically backed." "That even exceeds the level of the highest person- you know the highest person at Verkeer en Openbare Ruimte, she has to answer to higher managers, and even higher managers- I would like to have more support from those layers of management, for- you know- the common goals that we are working on and the ways- what you need to reach those goals."

Table 21: Barriers to the adoption of agile quotations, part 2 (note: no significant quotations from transcripts on Existing technologies/ infrastructure and Customer relationships and external conditions)

Thematic analysis Within the thematic analysis, top management support stood out as the largest potential barrier to an agile way of working. This was described not as top management intentionally blocking agile as a concept, but that practitioners could use more support from them in working towards common goals. Organizational culture, new skills needed, perceptions of agile, and organizational structure were also brought up as potential barriers for the Bicycle Program of the Municipality of Amsterdam. However, the barriers 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. This shows there are variations in how practitioners’ view their organization/working group. Which barriers are most relevant to the adoption of agile by planning departments in practice? In addition to the analysis from the interviews, the first part of the guided questionnaire sessions contributed to answering this targeted sub-question. Its results (Figure 25) suggest that practitioners see the barriers as relatively easy to overcome in their context. In particular, they do not see Reward systems & employee career consequences as a significant barrier.

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Figure 25: General barriers to agile questionnaire results

Taking the findings of the interviews and Figure 25 together, Table 22 breaks down the list of barriers from section 2.3 for the case of the bicycle program. This research finds organizational structure and top management support as the two most significant barriers. Barrier to adoption of agile

Bicycle Program of the Municipality of Amsterdam

Lack of effective collaboration and teamwork

In the case of the bicycle program it is not a barrier (though it could be elsewhere)

Organizational culture (resistant to change)

Resistance to change is present with people not used to or uncomfortable with this way of working

Management style

Overall, it is not a barrier in the case of the bicycle program (though it could be elsewhere, and depends on the group)

(New) skills, abilities, knowledge needed

This connects to organizational culture- some people may not have the skills to work in an agile way and are then resistant to change

Shared understanding of agile (mindset)

Getting everyone behind this way of working may be challenging

(Detrimental) perceptions of agile methodology

Some practitioners view agile and one of its methodologies (Scrum) negatively

Reward systems & employee career consequences

Not a significant barrier

Organizational structure

The organizational structure does not fit the changes and challenges that employees face in trying to reach their goals

Customer relationships and external conditions

Not a significant barrier

Existing technologies/infrastructure

Not a significant barrier

Top management support

Employees could receive more support from top management in working towards common goals

Table 22: Barriers to agile working in Bicycle Program of the Municipality of Amsterdam (red = significant barrier, orange = minor barrier, blank = not a significant barrier)

Collaboration, experimentation, continuous improvement?

Hahn, 2019

4.3.3

Answering sub-question 3

The testing of a pattern language and bicycle user experience suggest that there is no panacea for an agile way of working in planning departments. The semi-structured interviews and first part of the guided questionnaire sessions show that organizational structure and top management support are important factors for the planning context, and that organizational culture, the need for new skills, a shared mindset, and detrimental perceptions of agile should also be considered. When these barriers are addressed, agile might be adopted by planning departments in practice. The Bicycle Program of the Municipality of Amsterdam is already working in a partially agile way even while facing some of these barriers. This suggests that agile can be partially adopted without addressing every barrier in Table 22. While the barriers are not insurmountable, overcoming them will require deep change: building a shared mindset in an organization, shifting negative perceptions or changing an organizational structure, for example, are not easy tasks. The amount of work necessary to overcome the barriers will likely depend on the specific organization.

CHAPTER 5

CONCLUSION

Collaboration, experimentation, continuous improvement?

Hahn, 2019

5. Conclusion In order to answer the main research question, this research was broken down into three manageable sub-questions, using agile for operationalization. The sub-questions were then broken into targeted questions as shown in Figure 26.

Figure 26: Research (targeted sub-)questions structure

The literature review and semi-structured interviews showed that agile is accessible and relatable to planning departments, with some nuances. The ideas behind agile transcend software development, and its principles are relatable to planners, but people attempting to foster agile in a planning organization should be cautious not to force a specific methodology. The assisted process analysis and semi-structured interviews showed that- at least in the case of the Bicycle Program of the Municipality of Amsterdam- people are already partially working in an agile way. They excel with frequent collaboration and information driving decisions, for example, but gaps remain in responding to change and simplification (maximizing the amount of work not done). The Alexanderplein project showed how an iterative project strategy can work together with research and analysis to maneuver many stakeholders and a large organization. The guided questionnaire sessions and semi-structured interviews suggest that organizational structure and top management support are the most significant barriers that need to be overcome to adopt agile in planning practice. The testing of the pattern language and bicycle user experience concepts as potential solutions indicates there may not be a “silver bullet” solution to making planning departments agile. This leads to the main research question: How can planning departments transition to a way of working on projects that costs less money and time while better serving citizens? T his research has a nuanced answer: ● It is possible, and an agile way of working may be a place to start ● Understanding the context of the organization in which you’re working is key ● Experiment with parts of agile and with potential solutions; move towards agile in an agile way (ironically) ● Agile working does not have to be an all-or-nothing affair; even a partial agile way of working can bring benefits as was the case with the Bicycle Program of the Municipality of Amsterdam 62

Collaboration, experimentation, continuous improvement? ●

Hahn, 2019

It is important to stay focused on the ultimate goal- learning and growing as an organization to deliver projects that better serve citizens and use less time and money

If you are working in (with) a planning department, what can you take away from this? Actionable items are as follows: 1. Understand your working context and look for opportunities to intervene Even if agile isn’t officially known in an organization, many of its values and principles likely are. Figure out what is already in your organization and build on it. Consider the political situation and test incrementally. In the case of the Alexanderplein project, what was intended to be an experiment ended up becoming much more. 2. Look for and test (partial) solutions The pattern language and bicycle user experience can help to focus on people and interactions over processes and tools, but what are other potential solutions? Identify and test ideas that partially lead to a more agile way of working. These may already be happening in a workplace, or they may be new ideas. 3. Consider your people Individual people are also important to enabling an agile way of working, as was the willingness of staff to take risks and reach out to others in the Alexanderplein project. Hire, enable, and encourage these people to get working on projects. 4. Keep the focus on principles and goals The end goal is not to be certified “agile”. It is to grow, learn and better serve citizens. Communicate this, as there appears to be a remarkable difference between reception of common principles and buzzwords with significant baggage such as agile or scrum. The research has taken initial steps to explore an agile way of working in the context of the planning department. The following section reflects on limitations and elaborates on how additional research can take this further.

CHAPTER 6

REFLECTION

Collaboration, experimentation, continuous improvement?

Hahn, 2019

6. Reflection This section makes general reflections on the research and then goes into its limitations (first general, and then by method). Finally, directions for future research are proposed. How can planning departments transition to a way of working on projects that costs less money and time while better serving citizens? Using agile to operationalize answering this question enabled a structured research project. However, this decision also limited the scope of this research. Are there other ways of working that can enable planning departments to do the same? What might be learned from them? There are also connections between an agile way of working and broader ideas such as learning and continuous improvement. While not all practitioners perceive agile positively, organizational learning- “the capacity of organizational members to identify and examine problems and resolve them” (Gifford & Stalebrink, 2002, p. 647)- may be a goal that everyone can get behind. Gifford & Stalebrink (2002) explain that this includes improvement through single- and double-loop learning, which Nerur & Balijepally (2007) connect to iterative problem solving and the theoretical roots of agile (Figure 16 in section 4.1.1). These underlying things that agile is connected to- learning, problem solving, and continuous improvement- are powerful ideas. 6.1 Limitations Perhaps the largest limitation of this research is that it focuses only on Amsterdam as a case study. Some of the findings may not generalize to other planning departments. The concept of “better serves citizens” is important (Bolan, 2016), but is still- even after the research- difficult to define. For example, while the researcher made a judgement from the information learned that the Alexanderplein intervention was a success and does better serve citizens, there is subjectivity in this determination, and for any project there are always trade-offs. Finally, there was some struggle during the research to balance breadth and depth. While triangulation was important (see section 3.3), the need to complete all of the methods in the short period of time available for this thesis meant less time was available for each method. As a result, the quality and depth of some methods suffered. Literature review There are several points to reflect on for this method. There was not a current body of comprehensive work done around the question, so the results of this literature review should only be considered “an initial or preliminary conceptualization of the topic” (Torraco, 2005, p. 357). Additionally, there are limitations to the selection of the literature. This review took a more discussion-based approach rather than systematically focusing on search keywords. This was done with an exploratory purpose: to put different seemingly disparate puzzle pieces (ideas, disciplines, etc.) together that had not yet been examined in conjunction. The synthesis comes only from the perspective of one person- further perspectives on the subject would be useful- and only represents some of the literature that exists. It should also be noted that in comparing agile to planning support systems (PSS) as something to be adopted by planning departments, agile appears to be earlier in the research 65

Collaboration, experimentation, continuous improvement?

Hahn, 2019

lifecycle than PSS. While PSS is already in a discussion phase between PSS developers, planning practitioners, and academics, we are still figuring out what agile means in relation to urban planning. A discussion between people working on agile and planning practitioners will be important to develop (as in the case of PSS), but first there is still more theoretical exploration and reflection to be done on the subject. Semi-structured interviews In the semi-structured interviews, only practitioners from Amsterdam were spoken with and the sample size of 12 is limited. The researcher also has reflections on the interviewee selection process, use of the the word “agile” during the sessions, transcriptions, and order of interview questions. The Interviewee roles and rationale for selection table (Table 8 in section 3.2.2) lists a number of categories of roles that were interviewed. What it does not communicate is that in practice, the interviewee selection process evolved. The researcher encountered two phenomena: the reality of only being able to find and interview limited people and that individuals didn’t necessarily fit into one of the roles. For example, one interviewee was described as a planner by one person and a designer by another. Even within one role such as urban designer, there were nuances in what the people actually did: one interviewee talked much more about coordinating and working with different stakeholders, while the other was more concerned with the physical design. Originally, the researcher also wanted to interview stakeholders involved in human resources and budgeting at the municipality (they also impact the way of working), but was unable to interview these people. Before and throughout the interviews, a major concern of the researcher was how and when (or even if) to introduce the word “agile” during the sessions. In general, it is important to not be leading during interviews, and the word agile in particular comes with its own baggage. It was decided to introduce agile in the middle of the sessions and to attempt to give a balanced perspective on it. This has its limitations: while reviewing the agile lists, interviewees may have been inclined to say “yes, of course we're working in an agile way” in order to appear in a favorable light, while in the first part of the sessions information on how agile connects to their group and the project they bring up could have been missed. It should also be stated that there are imperfections of comparing responses about the agile across interviewees. Some people brushed over all the characteristics/practices while others gave more detailed thoughts on a few of them. The last parts to reflect on for this method are transcription and order of the interview questions. There are different perspectives on interview transcription, and it is “not only time consuming but also complex and fraught with technical dilemmas” (Halcomb & Davidson, 2006, p. 40). Because the transcripts were used only by the researcher to create codes in the thematic analysis, it was decided that the costs of verbatim transcription outweighed the potential benefits. Finally, throughout the interview process it became clear that there was always room to improve and tailor the question order. For example, the Semi-structured interviews item list (Table 9 in section 3.2.2) had questions about perceptions of project success before asking the interviewee to tell a story about a project of note to them. Towards

Collaboration, experimentation, continuous improvement?

Hahn, 2019

the end of the interviews, the researcher realized it may give the interviewee context to have them talk about their project before elaborating on what success meant to them. Assisted process analysis Perhaps just as much was learned from the reflection at the end of the session as through the exercise itself. It was pointed out that this was a simplification of the project and notably left out the human side of the process: many individual discussions occurred, risks were taken and sometimes tensions arose. One interviewee also brought up that the possibility of this project depended on both personal factors (i.e. are staff members working on it willing to take risks and reach out to other stakeholders) and organizational factors (i.e. how does the structure constrict or enable it). Another noted that the exercise itself was iterative process, and using dry-erase markers allowed the map to evolve. The person also thought that having more space to draw could have allowed the map to expand even more. Guided questionnaire sessions Limitations of this method that will be discussed are: its exploratory nature, limited scope, and question design. First, the method was exploratory. It only tested potential solutions, and the researcher didn’t explicitly know beforehand how they were connected to agile. As an initial testing it had a small sample size, which limited the analysis that could be done. By focusing on two concepts, it leaves out other potential solutions. The scope was limited in how it connected the potential solutions to agile. While the questionnaire says that a pattern language can help planning departments have Continuous testing & improvement and the bicycle user experience can help planning departments to Embrace conflict and discussion, blend chaos and order (both scored a 4.67 out of 5 average without an N/A response- 5 being “strongly agree”), it doesn’t reveal how or explain what that means. The specific connection between the solutions and (elements of) agile is something that needs deeper exploration. There are also some reflections on the question design. As per Krosnick & Presser (2010), it is recommended to avoid jargon in the questions. Given the agile-related terminology that was used and the fact that participants were doing the interview in their second language, this is an area where there may have been some misinterpretation. One participant brought up that he did not know how to answer for one item; the researcher said to use the N/A option, which means that his response(s) was bundled in with the actually intended N/A responses (and it is thus hard to interpret what these N/A responses actually mean). Given the exploratory nature of the method and the unknown connections between the solutions and agile, an “I don’t know” option would have been useful. The same agile lists (Tables 3-5 in section 2.3) from the semi-structured interviews were used to build the questions so that participants would be already somewhat familiar with them. However, there were imperfections with this, notably that some wording used negations (recommended against by Krosnick & Presser (2010)) and that some elements had multiple things squeezed into them (i.e. Frequent collaboration between roles within project team and with customer, which one participant noted were two distinct activities).

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Despite the limitations mentioned for this method, there are benefits of its format: the ability to prompt and probe during the sessions. Generally, “there is no one present to help respondents if they are having difficulty answering” in a questionnaire and “there is no opportunity to probe respondents to elaborate an answer” (Bryman, 2012, p. 234). The guided questionnaire session format enabled these without being a full-on interview. 6.2

Future research

Given the limitations of this research and the questions that have arisen during it, Table 23 proposes future research. There are multiple paths that can be taken, from focusing on a context outside of Amsterdam to exploring the use of an agile methodology, comparing an agile and non-agile project, and testing solutions. Limitation/question

Proposed future research

Focused only on (12) Amsterdam practitioners

Conduct similar research in different contexts to test how the findings generalize (including seeing how relatable agile principles are to other planning departments)

Agile is accessible to planning, but how to implement it is unclear

Critically explore the utility of using an agile methodology (i.e. scrum) in planning practice. If some utility exists, compare performance of different methodologies. Explore the usefulness and feasibility of developing a methodology more tailored to the planning context. If no utility exists, research working in an agile way without a prescribed methodology.

No comparison exists between an agile and non-agile project

Conduct a detailed comparative analysis between a more agile planning project (i.e. Alexanderplein intervention) and one that is not considered agile. Compare to what extent each project uses less time and money while better serving citizens.

Guided questionnaire sessions only tested two potential solutions with a small sample size

Thoroughly test the two solutions with more respondents and explore the specific connections between them and (elements of) agile in a more qualitative manner. Or, identify other potential solutions and test them as such.

Table 23: Limitations and questions leading to proposed future research

CHAPTER 7

REFERENCES

Collaboration, experimentation, continuous improvement?

7. References

Hahn, 2019

Abbas, N., Gravell, A. M., & Wills, G. B. (2008). Historical Roots of Agile Methods: Where Did “Agile Thinking” Come From? In P. Abrahamsson, R. Baskerville, K. Conboy, B. Fitzgerald, L. Morgan, & X. Wang (Eds.), Agile Processes in Software Engineering and Extreme Programming (pp. 94–103). Limerick: Springer. https://doi.org/10.1023/A:1005132430171 Adams, W. C. (2015). Conducting Semi-Structured Interviews. In K. E. Newcomer, H. P. Hatry, & J. S. Wholey (Eds.), Handbook of Practical Program Evaluation (4th ed., pp. 492–505). Jossey-Bass. https://doi.org/10.1002/9781119171386.ch19 alelealv. (2018, September 21). #Alexanderplein en #Amsterdam hicieron piloto y quitaron semáforos en intersección con flujos altos de ciclistas, autos, peatones y tranvía. El resultado de encuesta fue mejora de seguridad y 60% pensó que la congestión disminuyó https://www.theguardian.com/environment/bike-blog/2017/sep/22/what-happens-ifyou-turn-off-the-traffic-lights https://www.google.com/maps/place/52°21'48.8"N+4°55'07.1"E/@52.363545,4.9164 513,17z/data=!3m1!4b1!4m5!3m4!1s0x0:0x0!8m2!3d52.363545!4d4.91864?hl=es-MX [Tweet]. https://twitter.com/alelealv/status/1043113458974126080 Alias, Z., Zawawi, E. M. A., Yusof, K., & Aris, N. (2014). Determining Critical Success Factors of Project Management Practice: A conceptual framework. Procedia - Social and Behavioral Sciences, 153, 61–69. https://doi.org/10.1016/j.sbspro.2014.10.041 Amsterdam North-South Metro Line Opens 22 July 2018. (2018, July 19). AmsterdamTips.Com. Retrieved from http://www.amsterdamtips.com/amsterdam-north-south-line Andersson, R., & Bendix, L. (2006). eXtreme teaching: A framework for continuous improvement. Computer Science Education, 16(3), 175–184. https://doi.org/10.1080/08993400600912335 Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management, 17(6), 337–342. Attarzadeh, I., & Ow, S. H. (2008). Project Management Practices: The Criteria for Success or Failure. Communications of the IBIMA, 1, 234–241. Barriball, K. L., & While, A. (1994). Collecting data using a semi-structured interview: a discussion paper. Journal of Advanced Nursing, 19, 328–335. Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Manifesto for Agile Software Development. Biazzo, S. (2002). Process mapping techniques and organisational analysis: Lessons from sociotechnical system theory. Business Process Management Journal, 8(1), 42–52. https://doi.org/10.1108/14637150210418629 Bicicleto_ZGZ. (2019, April 8). Cuando se eliminaron los semáforos en Alexanderplein (Ámsterdam) hubo quien preveía una masacre. Semanas después nadie se acuerda de esas lucecitas. La interacción social resolvió el problema. [Tweet]. https://twitter.com/Bicicleto_ZGZ/status/1115172850455986183 Bolan, R. S. (2016). My 60 Years as a Planner. Journal of the American Planning Association, 82(3), 280–287. https://doi.org/10.1080/01944363.2015.1137779 70

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Braun, V., & Clarke, V. (2006). Using thematic analysis in psychology. Qualitative Research in Psychology, 3(2), 77–101. https://doi.org/10.1191/1478088706qp063oa Bryman, A. (2012). Social Research Methods (4th ed.). Oxford: Oxford University Press. Budzier, A., & Flyvbjerg, B. (2013). Making Sense of the Impact and Importance of Outliers in Project Management Through the Use of Power Laws. In IRNOP (International Research Network on Organizing by Projects) Conference. Oslo. Retrieved from http://papers.ssrn.com/abstract=2289549 Campbell, H., Tait, M., & Watkins, C. (2014). Is There Space for Better Planning in a Neoliberal World?: Implications for Planning Practice and Theory. Journal of Planning Education and Research, 34(1), 45–59. https://doi.org/10.1002/9781119084679.ch10 Cantarelli, C. C., Flyvbjerg, B., Molin, E. J. E., & Wee, B. van. (2010). Cost Overruns in Large-scale Transportation Infrastructure Projects: Explanations and Their Theoretical Embeddedness. EJTIR, 10(1), 5–18. Carter, N., Bryant-Lukosius, D., DiCenso, A., Blythe, J., & Neville, A. J. (2014). The Use of Triangulation in Qualitative Research. Oncology Nursing Forum, 41(5), 545–547. https://doi.org/10.1188/14.ONF.545-547 Chan, F. K. Y., & Thong, J. Y. L. (2009). Acceptance of agile methodologies: A critical review and conceptual framework. Decision Support Systems, 46(4), 803–814. https://doi.org/10.1016/j.dss.2008.11.009 Clark, K. R., & Buckley, M. B. (2017). Using a Synthesis Matrix to Plan a Literature Review. Radiologic Technology, 88(3), 354–357. Clark, W. W. (2007). Partnerships in creating agile sustainable development communities. Journal of Cleaner Production, 15(3), 294–302. https://doi.org/10.1016/j.jclepro.2006.02.008 Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer, 34(11), 131–133. https://doi.org/10.1109/2.963450 Cohen, J. (2017, October 5). Amsterdam Rethinks the Traffic Light’s Role in City Planning. Next City. Retrieved from https://nextcity.org/daily/entry/amsterdam-traffic-lights-removed Completion of new metro line unsure as Alderman resigns over cost overruns. (2009, February 19). DutchAmsterdam.Nl. Retrieved from http://www.dutchamsterdam.nl/583-north-south-amsterdam-metro-line Copenhagenize Design Co. (2014). Desire Lines - Amsterdam. Retrieved December 5, 2018, from https://copenhagenize.eu/desire-lines-amsterdam/ Cullen, T. (2017, January 4). It Took a Very, Very Long Time for the Second Avenue Subway to Be a Reality. Commercial Observer. Retrieved from https://commercialobserver.com/2017/01/it-took-a-very-very-long-time-for-the-secon d-avenue-subway-to-be-a-reality/ Damelio, R. (2011). The Basics of Process Mapping (2nd ed.). Boca Raton: CRC Press. Davis, K. (2014). Different stakeholder groups and their perceptions of project success. International Journal of Project Management, 32, 189–201. https://doi.org/http://dx.doi.org/10.1016/j.ijproman.2013.02.006 Der nackte Ampelwahnsinn oder sinnvolle Verkehrssteuerung? (2018, April 25). Winterthurer Zeitung. Retrieved from

Collaboration, experimentation, continuous improvement?

Hahn, 2019Â

www.winterthurer-zeitung.ch/winterthur/detail/article/der-nackte-ampelwahnsinn-od er-sinnvolle-verkehrssteuerung-00139573/Â DeWit, A. (1988). Measurement of project success. International Journal of ProjectÂ Management, 6(3), 164â&#x20AC;&#x201C;170. https://doi.org/10.1016/0263-7863(88)90043-9Â Dimitriou, H. T., Ward, E. J., & Wright, P. G. (2013). Mega transport projects-Beyond theÂ â&#x20AC;&#x153;iron triangleâ&#x20AC;?: Findings from the OMEGA research programme. Progress inÂ Planning, 86, 1â&#x20AC;&#x201C;43. https://doi.org/10.1016/j.progress.2013.03.001Â DingsĂ¸yr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agileÂ methodologies: Towards explaining agile software development. The Journal ofÂ Systems and Software, 85(6), 1213â&#x20AC;&#x201C;1221. https://doi.org/10.1016/j.jss.2012.02.033Â DybĂĽ, T., & DingsĂ¸yr, T. (2009). What Do We Know about Agile Software Development?Â IEEE Software, 26(5), 6â&#x20AC;&#x201C;9. https://doi.org/10.1021/i650563a753Â Ebbesen, J. B., & Hope, A. J. (2013). Re-imagining the Iron Triangle: EmbeddingÂ Sustainability into Project Constraints. PM World Journal, 2(3). Retrieved fromÂ https://pmworldjournal.net/article/re-imagining-the-iron-triangle-embedding-sustaina bility-into-project-constraints/Â emmapeijnenburg. (2017, January 19). Morning world đ&#x;&#x2018;&#x2039;đ&#x;?źđ&#x;&#x2019;&#x2022; ......#amsterdamÂ visitamsterdam #sunrise #gramthedam #skiesonfire #heysunshine #pastelskiesÂ #cityscape #morning #riseandshine #guardiancities #upandrunning #onthegoÂ #exploremore #amsterdameast [Instagram photo].Â https://www.instagram.com/p/BPcD2fjhZcV/Â fietsprofessor. (2018, April 20). Traffic lights make sense from a car perspective. But whatÂ happens if you turn off the lights? From stop-and-go (top) to a fluid choreographyÂ (bottom)! ~ Alexanderplein, Amsterdam. More details about our study:Â https://www.theguardian.com/environment/bike-blog/2017/sep/22/what-happens-ifyou-turn-off-the-traffic-lights [Tweet].Â https://twitter.com/fietsprofessor/status/987305739013238785Â Fishman, E., Schepers, P., & Kamphuis, C. B. M. (2015). Dutch Cycling: Quantifying theÂ Health and Related Economic Benefits. American Journal of Public Health, 105(8),Â e13â&#x20AC;&#x201C;e15. https://doi.org/10.2105/AJPH.2015.302724Â Flyvbjerg, B. (2007). Policy and planning for large-infrastructure projects: problems,Â causes, cures. Environment and Planning B: Planning and Design, 34(4), 578â&#x20AC;&#x201C;597.Â https://doi.org/10.1068/b32111Â Flyvbjerg, B. (2014). What You Should Know About Megaprojects and Why: An Overview.Â Project Management Journal, 45(2), 6â&#x20AC;&#x201C;19. https://doi.org/10.1002/pmj.21409Â Flyvbjerg, B., Holm, M. K. S., & Buhl, S. L. (2003). How common and how large are costÂ overruns in transport infrastructure projects? Transport Reviews, 23(1), 71â&#x20AC;&#x201C;88.Â https://doi.org/10.1080/01441640309904Â Flyvbjerg, B., Holm, M. S., & Buhl, S. (2002). Underestimating costs in public worksÂ projects: Error or lie? Journal of the American Planning Association, 68(3), 279â&#x20AC;&#x201C;295.Â https://doi.org/10.1080/01944360208976273Â Flyvbjerg, B., Holm, M. S., & Buhl, S. (2004). What Causes Cost Overrun in TransportÂ Infrastructure Projects? Transport Reviews, 24(1), 3â&#x20AC;&#x201C;18.Â https://doi.org/https://doi.org/10.1080/0144164032000080494aÂ Freedman, R. (2009, June 16). The roots of agile project management. TechRepublic.Â Retrieved fromÂ

72Â

Collaboration, experimentation, continuous improvement?

Hahn, 2019

https://www.techrepublic.com/blog/tech-decision-maker/the-roots-of-agile-project-m anagement/ Gandomani, T. J., & Nafchi, M. Z. (2016). Agile transition and adoption human-related challenges and issues: A Grounded Theory approach. Computers in Human Behavior, 62, 257–266. https://doi.org/10.1016/j.chb.2016.04.009 Garrard, J., Rissel, C., & Bauman, A. (2012). Health Benefits of Cycling. In J. Pucher & R. Buehler (Eds.), City Cycling (pp. 31–55). Cambridge: MIT Press. Geels, F.W., McMeekin, A., & Pfluger, B. (2018). Socio-technical scenarios as a methodological tool to explore social and political feasibility in low-carbon transitions: Bridging computer models and the multi-level perspective in UK electricity generation (2010–2050). Technological Forecasting and Social Change. https://doi.org/https://doi.org/10.1016/j.techfore.2018.04.001 Geels, Frank W. (2002). Technological transitions as evolutionary reconfiguration processes: A multi-level perspective and a case-study. Research Policy, 31, 1257–1274. https://doi.org/10.1016/S0048-7333(02)00062-8 Geels, Frank W. (2011). The multi-level perspective on sustainability transitions: Responses to seven criticisms. Envrionmental Innovation and Societal Transformations, 1, 24–40. https://doi.org/10.1016/j.eist.2011.02.002 Geels, Frank W. (2012). A socio-technical analysis of low-carbon transitions: introducing the multi-level perspective into transport studies. Journal of Transport Geography, 24, 471–482. https://doi.org/10.1016/j.jtrangeo.2012.01.021 Geels, Frank W. (2018). Disruption and low-carbon system transformation: Progress and new challenges in socio-technical transitions research and the Multi-Level Perspective. Energy Research & Social Science, 37, 224–231. https://doi.org/10.1016/j.erss.2017.10.010 Geels, Frank W., Schwanen, T., Sorrell, S., Jenkins, K., & Sovacool, B. (2018). Reducing energy demand through low carbon innovation: A sociotechnical transitions perspective and thirteen research debates. Energy Research & Social Science, 40, 23–35. Geertman, S., & Stillwell, J. (2004). Planning support systems: An inventory of current practice. Computers, Environment and Urban Systems, 28(4), 291–310. https://doi.org/10.1016/S0198-9715(03)00024-3 Geertman, S., Toppen, F., & Stillwell, J. (Eds.). (2013). Planning Support Systems for Sustainable Urban Development. Springer. Gemeente Amsterdam. (2013). MobiliteitsAanpak Amsterdam 2030. Retrieved from https://assets.amsterdam.nl/publish/pages/867885/mobiliteitsaanpak_amsterdam_2 0303.pdf Gemeente Amsterdam. (2018). Plan Amsterdam 02 2018- Giving way to cyclists. Retrieved from https://issuu.com/gemeenteamsterdam/docs/planam-02-2018/19 Giezen, M. (2012). Keeping it simple? A case study into the advantages and disadvantages of reducing complexity in mega project planning. International Journal of Project Management, 30(7), 781–790. https://doi.org/10.1016/j.ijproman.2012.01.010 Gifford, J. L., & Stalebrink, O. J. (2002). Remaking transportation organizations for the 21st century: Consortia and the value of organizational learning. Transportation

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Research Part A: Policy and Practice, 36(7), 645–657. https://doi.org/10.1016/S0965-8564(01)00028-3 Glaser, M. (2017, September 22). What happens if you turn off the traffic lights? The Guardian. Retrieved from https://www.theguardian.com/environment/bike-blog/2017/sep/22/what-happens-ifyou-turn-off-the-traffic-lights Gössling, S., & Choi, A. S. (2015). Transport transitions in Copenhagen: Comparing the cost of cars and bicycles. Ecological Economics, 113, 106–113. https://doi.org/10.1016/j.ecolecon.2015.03.006 Gotschi, T. (2011). Costs and benefits of bicycling investments in Portland, Oregon. Journal of Physical Activity and Health, 8(1), S49–S58. https://doi.org/10.1123/jpah.8.s1.s49 Guest, G., Bunce, A., & Johnson, L. (2006). How Many Interviews Are Enough? An Experiment with Data Saturation and Variability. Field Methods, 18(1), 59–82. https://doi.org/10.1177/1525822X05279903 Gutenschwager, G. A. (1973). The Time-Budget—Activity Systems Perspective in Urban Research and Planning. Journal of the American Institute of Planners, 39(6), 378–387. https://doi.org/10.1080/01944367308977431 Hahn, T. (2016). Designing a Bicycle User Experience. Retrieved February 27, 2019, from https://www.bicycleuserexperience.com/ Halcomb, E. J., & Davidson, P. M. (2006). Is verbatim transcription of interview data always necessary? Applied Nursing Research, 19(1), 38–42. https://doi.org/10.1016/j.apnr.2005.06.001 Hall, P. (1996). Cities of tomorrow : an intellectual history of urban planning and design in the twentieth century. Oxford: Blackwell. Highsmith, J. (2002). What Is Agile Software Development? The Journal of Defense Software Engineering, 15(10), 4–9. https://doi.org/10.1109/2.947100 Hussein, B. A., Ahmad, S. B. S., & Zidane, Y. J. T. (2015). Problems Associated with Defining Project Success. Procedia Computer Science, 64, 940–947. https://doi.org/10.1016/j.procs.2015.08.611 Ika, L. A. (2009). Project Success as a Topic in Project Management Journals. Project Management Journal, 40(4), 6–19. https://doi.org/10.1002/pmj.20137 Jha, K. N., & Iyer, K. C. (2007). Commitment, coordination, competence and the iron triangle. International Journal of Project Management, 25(5), 527–540. https://doi.org/10.1016/j.ijproman.2006.11.009 Jin, D. J., & Stough, R. S. (1996). Agile Cities: The Role of Intelligent Transportation Systems in Building the Learning Infrastructure for MEtropolitan Economic Development. In IEEE Intemational Symposium on Technology and Society (pp. 448–456). Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001 Jovchelovitch, S., & Bauer, M. W. (2000). Narrative interviewing. London: LSE Research Online. Retrieved from http://eprints.lse.ac.uk/2633

Collaboration, experimentation, continuous improvement?

Hahn, 2019Â

Jugdev, K., & MĂźller, R. (2005). A Retrospective Look At Our Evolving Understanding ofÂ Project Success. Project Management Journal, 36(4), 19â&#x20AC;&#x201C;31.Â https://doi.org/10.1109/EMR.2006.261387Â Karami, H., & Olatunji, O. A. (2018). Key success factors in marine infrastructures, aÂ review. In 42nd AUBEA Conference 2018: Educating Building Professionals for theÂ Future in the Globalised World (pp. 121â&#x20AC;&#x201C;128).Â Kemp, R., Rip, A., & Schot, J. W. (2001). Constructing transition paths through theÂ management of niches. In R. Garud & P. Karnoe (Eds.), Path Dependence andÂ Creation (pp. 269â&#x20AC;&#x201C;299). Mahwah, NJ: Lawrence Erlbaum.Â kentslundberg. (2017, October 5). â&#x20AC;&#x153;traffic lights are infrastructure for cars, not anÂ infrastructure for people on bikes & people walking" [Tweet].Â https://twitter.com/kentslundberg/status/916020462961827840Â Klosterman, R. E., & Pettit, C. J. (2005). An Update on Planning Support Systems.Â Environment and Planning B: Planning and Design, 32(4), 477â&#x20AC;&#x201C;484.Â https://doi.org/10.1068/b3204edÂ Krosnick, J. A., & Presser, S. (2010). Question and Questionnaire Design. In Handbook ofÂ Survey Research (2nd ed., pp. 263â&#x20AC;&#x201C;313). Emerald Group Publishing Limited.Â Lang, G. (2017). Agile Learning: Sprinting Through the Semester. Information SystemsÂ Education Journal (ISEDJ), 15(3), 14â&#x20AC;&#x201C;21.Â Leech, B. L. (2002). Asking questions: Techniques for semistructured interviews. PS -Â Political Science and Politics, 35(4), 665â&#x20AC;&#x201C;668.Â https://doi.org/10.1017/S1049096502001129Â Lehtonen, M. (2014). Evaluating megaprojects: From the â&#x20AC;&#x2DC;iron triangleâ&#x20AC;&#x2122; to networkÂ mapping. Evaluation, 20(3), 278â&#x20AC;&#x201C;295. https://doi.org/10.1177/1356389014539868Â lennartnout. (2019, January 29). We took our 360 degree camera out for a spin onÂ Alexanderplein in Amsterdam. Experience for yourself what a traffic-light-lessÂ protected intersection feels like in 4k!Â https://www.youtube.com/watch?v=NU8ofUnb74k&feature=youtu.be [Tweet].Â https://twitter.com/lennartnout/status/1090197242923962368Â Luna, A. J. H. de O., Kruchten, P., & Moura, H. P. de. (2015). Agile Governance Theory:Â conceptual development. In D. M. G. Sakata (Ed.), 12th International Conference onÂ Management of Technology and Information Systems. SĂŁo Paulo: FEA-USP.Â Mathison, S. (1988). Why Triangulate? Educational Researcher, 17(2), 13â&#x20AC;&#x201C;17.Â https://doi.org/10.3102/0013189X017002013Â mattresses_of_amsterdam. (2016, November 15). Its down there somewhere. #đ&#x;&#x2022;ľđ&#x;?ťÂ #garbagemikado #amsterdam #autumn #đ&#x;? #đ&#x;?&#x201A; #mattress [Instagram photo].Â https://www.instagram.com/p/BM2MH-HhyW3/Â Meyer, D. (2018, December 20). DOTâ&#x20AC;&#x2122;s $200-Million Rotunda Fix Leaves Cyclists inÂ Danger. Streetsblog NYC. Retrieved fromÂ https://nyc.streetsblog.org/2018/12/20/dots-200-million-rotunda-fix-leaves-cyclists-in -danger/Â Mobiel21 & Bike Citizens. (2019). Ping Amsterdam - PING if you care! Retrieved FebruaryÂ 22, 2019, from https://pingifyoucare.eu/nl/amsterdam/Â modacitylife. (2019, April 7). When the traffic lights were turned off in Amsterdamâ&#x20AC;&#x2122;sÂ Alexanderplein, some critics predicted carnage. Within weeks, the response wasÂ overwhelming: â&#x20AC;&#x153;What traffic lights?â&#x20AC;? Turns out social trust and interaction are idealÂ

75Â

Collaboration, experimentation, continuous improvement?

Hahn, 2019

for solving human-scale and slow-speed traffic situations. [Tweet]. https://twitter.com/modacitylife/status/1114930532628955136 Moradi, A., & Vagnoni, E. (2018). A multi-level perspective analysis of urban mobility system dynamics: What are the future transition pathways? Technological Forecasting & Social Change, 126, 231–243. https://doi.org/10.1016/j.techfore.2017.09.002 Morris, D. (2017). The over capitalization of Scrum. Retrieved June 9, 2019, from https://davidjcmorris.com/2017/05/the-over-capitalization-of-scrum/ Müller, R., & Jugdev, K. (2012). Critical success factors in projects: Pinto, Slevin, and Prescott – the elucidation of project success. International Journal of Managing Projects in Business, 5(4), 757–775. https://doi.org/10.1108/17538371211269040 Munro, G. (2015). A manifesto for agile urbanism : a citizen-led blueprint for smart cities, smart communities, and smart democracy. Preprint. Retrieved from https://www.researchgate.net/publication/325487088_A_manifesto_for_agile_urba nism_a_citizen-led_blueprint_for_smart_cities_smart_communities_and_smart_de mocracy Muylaert, C. J., Sarubbi Jr, V., Gallo, P. R., Neto, M. L. R., & Reis, A. O. A. (2014). Narrative interviews: an important resource in qualitative research. Revista Da Escola de Enfermagem Da USP, 48(spe2), 193–199. https://doi.org/10.1590/S0080-623420140000800027 Narayanamurthi. (2017). Top 5 Industries That Are Adopting Agile Other Than Software. Retrieved February 27, 2019, from http://agileseeds.com/agile-in-other-industries/ Nasri, V. (2013). Design and construction of the Second Avenue subway project in New York. Geomechanics and Tunnelling, 6(5), 528–541. https://doi.org/10.1002/geot.201300044 Nerur, S., & Balijepally, V. (2007). Theoretical reflections on agile development methodologies. Communications of the ACM, 50(3), 79–83. https://doi.org/10.1145/1226736.1226739 Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), 73–78. Nolan, M., & Behi, R. (1995). Triangulation: the best of all worlds? British Journal of Nursing, 4(14), 829–832. https://doi.org/10.12968/bjon.1995.4.14.829 North-South Amsterdam metro line delayed (again). (2016, July 8). DutchNews. Retrieved from https://www.dutchnews.nl/news/2016/07/north-south-amsterdam-metro-line-delaye d-again/ Nowotarski, P., & Pasławski, J. (2016). Lean and Agile Management Synergy in Construction of High-Rise Office Building. Archives of Civil Engineering, 62(4), 133–148. Papachristos, G., Sofianos, A., & Adamides, E. (2013). Environmental Innovation and Societal Transitions System interactions in socio-technical transitions: Extending the multi-level perspective. Environmental Innovation and Societal Transitions, 7, 53–69. https://doi.org/10.1016/j.eist.2013.03.002 Pathirana, A., Radhakrishnan, M., Ashley, R., Quan, N. H., & Zevenbergen, C. (2018). Managing urban water systems with significant adaptation deficits—unified

Collaboration, experimentation, continuous improvement?

Hahn, 2019

framework for secondary cities: part II—the practice. Climatic Change, 149(1), 57–74. https://doi.org/10.1007/s10584-017-2059-0 Pinto, J. K., & Serrador, P. (2015). Does Agile work? - A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040–1051. https://doi.org/10.1016/j.ijproman.2015.01.006 Plotch, P. M. (2015). Waiting more than 100 years for the second avenue subway to arrive. Journal of Planning History, 14(4), 309–328. https://doi.org/10.1177/1538513215590496 Poolton, J., Ismail, H. S., Reid, I. R., & Arokiam, I. C. (2006). Agile marketing for the manufacturing-based SME. Marketing Intelligence & Planning, 24(7), 681–693. Pope-Sussman, R. (2016, December 29). The Insanely Expensive Second Avenue Subway Explained. Gothamist. Retrieved from http://gothamist.com/2016/12/29/2nd_ave_subway_explainer.php Prabhakar, G. P. (2008). What is Project Success : A Literature Review. International Journal of Business and Management, 3(9), 3–10. Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide) (5th ed.). Newtown Square: Project Management Institute, Inc. Pulse of the Profession: 9th Global Project Management Survey. (2017). Radhakrishnan, M., Pathak, T. M., Irvine, K., & Pathirana, A. (2017). Scoping for the operation of agile urban adaptation for secondary cities of the global south: Possibilities in Pune, India. Water, 9(12), 939. https://doi.org/10.3390/w9120939 Radujković, M., & Sjekavica, M. (2017). Project Management Success Factors. Procedia Engineering, 196, 607–615. https://doi.org/10.1016/j.proeng.2017.08.048 Rich, J. L., Chojenta, C., & Loxton, D. (2013). Quality, Rigour and Usefulness of Free-Text Comments Collected by a Large Population Based Longitudinal Study - ALSWH. PLOS ONE, 8(7). https://doi.org/10.1371/journal.pone.0068832 Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016a, April 20). The Secret History of Agile Innovation. Harvard Business Review. Retrieved from https://hbr.org/2016/04/the-secret-history-of-agile-innovation Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016b, May). Embracing Agile. Harvard Business Review, 40–48, 50. Retrieved from https://hbr.org/2016/05/embracing-agile Rip, A., & Kemp, R. (1996). Towards a Theory of Socio-Technical Change. Mimeo University of Twente, Report prepared for Batelle Pacific Northwest Laboratories, Washington, DC. RobertWeetman. (2019, February 8). You have this the wrong way around. In the NL/Amsterdam, they are *taking out* traffic signals at junctions where the number of bikes has grown. Alexanderplein for example (videos here https://robertweetman.wordpress.com/2017/10/12/what-nobody-told-me-1/) Traffic signals not required even for amazingly busy bike traffic. [Tweet]. https://twitter.com/RobertWeetman/status/1093874844633100288 Rosenthal, B. M. (2017). The most expensive mile of subway track on earth. Retrieved October 23, 2018, from https://www.todayonline.com/world/most-expensive-mile-subway-track-earth

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Schmitt, A. (2019). Seattle Tosses Out Rulebook to Protect Pedestrians. Streetsblog USA. Retrieved from https://usa.streetsblog.org/2019/02/05/seattle-tosses-out-the-rulebook-to-protect-p edestrians/ Scottish Qualifications Authority. (2007). Process Analysis. Retrieved February 12, 2019, from https://www.sqa.org.uk/e-learning/ProjMan03CD/page_11.htm Scruggs, G. (2018, September 19). How agile is your city? Urban experts call for more flexible land use. Reuters. Retrieved from https://www.reuters.com/article/us-global-cities-development/how-agile-is-your-cityurban-experts-call-for-more-flexible-land-use-idUSKCN1LZ2K1 Shawky, D. M. (2014). Traditional vs Agile Development: A Comparison Using Chaos Theory. In 2014 9th International Conference on Software Paradigm Trends (ICSOFT-PT) (pp. 109–114). Shenhar, A., Levy, O., & Dvir, D. (1997). Mapping the Dimensions of Project Success. Project Management Journal, 28(2), 5–13. siebeswart. (2016, December 2). day 162.61 unexpected perspective #siebeswart #swartwit #blackandwhite #zwartwitfotografie #blackandwhitephotography #bnwphotography #bnw_captures #cityscape #still #amsterdam #streetstill #gramthedam [Instagram photo]. https://www.instagram.com/p/BNgd8l9BBSv/ Smith, A., Voß, J.-P., & Grin, J. (2010). Innovation studies and sustainability transitions: The allure of the multi-level perspective and its challenges. Research Policy, 39(4), 435–448. https://doi.org/10.1016/j.respol.2010.01.023 Streule, T., Miserini, N., Bartlomé, O., Klippel, M., & García de Soto, B. (2016). Implementation of Scrum in the Construction Industry. Procedia Engineering, 164, 269–276. https://doi.org/10.1016/j.proeng.2016.11.619 Swanson, J. (2013). The Business Process Analysis for a Project Manager. Retrieved February 12, 2019, from https://pmhut.com/the-business-process-analysis-for-a-project-manager te Brommelstroet, M. (2013). Performance of Planning Support Systems What is it, and how do we report on it? Computers Environment and Urban Systems, 41, 299–308. https://doi.org/10.1016/j.compenvurbsys.2012.07.004 te Brömmelstroet, M. (2012). Transparency, flexibility, simplicity: From buzzwords to strategies for real PSS improvement. Computers, Environment and Urban Systems, 36(1), 96–104. https://doi.org/10.1016/j.compenvurbsys.2011.06.002 te Brömmelstroet, M. (2017). PSS are more user-friendly, but are they also increasingly useful? Transportation Research Part A: Policy and Practice, 104, 96–107. https://doi.org/10.1016/j.tra.2016.05.012 te Brömmelstroet, M., Nello-Deakin, S., Quillien, J., & Bhattacharya, I. (2018). Towards a pattern language for cycling environments: merging variables and narratives. Applied Mobilities. https://doi.org/10.1080/23800127.2018.1505261 te Brömmelstroet, M., Nikolaeva, A., Glaser, M., Nicolaisen, M. S., & Chan, C. (2017). Travelling together alone and alone together: mobility and potential exposure to diversity. Applied Mobilities, 2(1), 1–15. https://doi.org/10.1080/23800127.2017.1283122 Thurmond, V. A. (2001). The Point of Triangulation. Journal of Nursing Scholarship, 33(3), 253–258. https://doi.org/10.1111/j.1547-5069.2001.00253.x

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Tolf, S., Nystrom, M. E., Tishelman, C., Brommels, M., & Hansson, J. (2015). Agile, a guiding principle for health care improvement? International Journal of Health Care Quality Assurance, 28(5), 468–493. Toor, S. u R., & Ogunlana, S. O. (2010). Beyond the “iron triangle”: Stakeholder perception of key performance indicators (KPIs) for large-scale public sector development projects. International Journal of Project Management, 28, 228–236. https://doi.org/10.1016/j.ijproman.2009.05.005 Torraco, R. J. (2005). Writing Integrative Literature Reviews: Guidelines and Examples. Human Resource Development Review, 4(3), 356–367. https://doi.org/10.1177/1534484305278283 van Beurden, M. (2016). Shutting of the lights: how to study a disruptive cycling intervention? Retrieved May 21, 2019, from http://cyclingacademics.blogspot.com/2016/09/shutting-of-lights-how-to-study.html? m=1 Van Leeuwen, A. (2018, July 21). The North-South subway line in Amsterdam is finally open! DutchReview. Retrieved from https://dutchreview.com/expat/traveling/the-north-south-subway-line-in-amsterdam-i s-finally-open/ van Vliet, D. (2016, November 30). “Sta fietsen door rood gewoon toe.” AD. Retrieved from https://www.ad.nl/rotterdam/sta-fietsen-door-rood-gewoon-toe~a4fd2bdd/ Van Wee, B., & Banister, D. (2016). How to Write a Literature Review Paper? Transport Reviews, 36(2), 278–288. https://doi.org/10.1080/01441647.2015.1065456 Vasarini Lopes, M. (2018). Mobility for people: studying desirable social interactions in design and assessment of street intersections. University of Amsterdam. Retrieved from http://www.scriptiesonline.uba.uva.nl/en/scriptie/670530 Velibeyoglu, K., Sargin, F. G., Bingöl, E., Saygin, Ö., & Yildiz, B. Y. (2016). Scrum for Design: Pedogogical Implications in Managing Urban Design Studio. In Designing Urban Design: Towards a Holistic Perspective. Ankara: Middle East Technical University. Viechnicki, P., & Kelkar, M. (2017). Agile by the numbers. Retrieved January 23, 2019, from https://www2.deloitte.com/insights/us/en/industry/public-sector/agile-in-government -by-the-numbers.html Vonk, G., & Geertman, S. (2008). Improving the Adoption and Use of Planning Support Systems in Practice. Applied Spatial Analysis and Policy, 1(3), 153–173. https://doi.org/10.1007/s12061-008-9011-7 Vonk, G., Geertman, S., & Schot, P. (2005). Bottlenecks blocking widespread usage of planning support systems. Environment and Planning A, 37(5), 909–924. https://doi.org/10.1068/a3712 Wagenbuur, M. (2018). Intersection upgrade: a Banana and a Chips Cone. Retrieved December 5, 2018, from https://bicycledutch.wordpress.com/2018/04/10/intersection-upgrade-a-banana-anda-chips-cone/ Webber, M. M., & Horst, W. J. R. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4, 155–169. Retrieved from

Collaboration, experimentation, continuous improvement?

Hahn, 2019

https://link.springer.com/content/pdf/10.1007%2FBF01405730.pdf%0Ahttp://www.uc tc.net/mwebber/Rittel+Webber+Dilemmas+General_Theory_of_Planning.pdf Webster, J., & Watson, R. T. (2002). Analyzing the Past to Prepare for the Future: Writing a Literature Review. MIS Quarterly, 26(2), xiii–xxiii. Weiss, R. S. (1995). Interviewing. In Learning From Strangers: The Art and Method of Qualitative Interview Studies (1st ed., pp. 61–119). New York: The Free Press. What is Agile Software Development? (n.d.). Retrieved January 23, 2019, from https://www.agilealliance.org/agile101/ White, G. R. T., & Cicmil, S. (2016). Knowledge acquisition through process mapping: Factors affecting the performance of work-based activity. International Journal of Productivity and Performance Management, 65(3), 302–323. https://doi.org/10.1108/IJPPM-01-2014-0007 Whiting, L. (2008). Semi-structured interviews: guidance for novice researchers. Nursing Standard, 22(23), 35–40. Whitmarsh, L. (2012). How useful is the Multi-Level Perspective for transport and sustainability research? Journal of Transport Geography, 24, 483–487. https://doi.org/10.1016/j.jtrangeo.2012.01.022 Woodcock, J., Edwards, P., Tonne, C., Armstrong, B. G., Ashiru, O., Banister, D., … Roberts, I. (2009). Public health benefits of strategies to reduce greenhouse-gas emissions: urban land transport. The Lancet, 374(9705), 1930–1943. https://doi.org/10.1016/S0140-6736(09)61716-5 Yglesias, M. (2017, January 1). NYC’s brand new subway is the most expensive in the world — that’s a problem. Vox. Retrieved from https://www.vox.com/policy-and-politics/2017/1/1/14112776/new-york-second-avenuesubway-phase-2 Zorn, T. (n.d.). Designing and Conducting Semi-Structured Interviews for Research. Retrieved from http://home.utah.edu/~u0326119/Comm4170-01/resources/Interviewguidelines.pdf

CHAPTER 8

APPENDICES

Collaboration, experimentation, continuous improvement? 8.

Hahn, 2019

Appendices

Process mapping fact sheet… 83 Full questionnaire… 84 Ethics and research consent… 89

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Process mapping fact sheet:

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Full questionnaire:

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Collaboration, experimentation, continuous improvement?

Hahn, 2019

Ethics and research consent:

As this thesis included interviews, interviewee consent was necessary to conduct the research. The researcher both received oral consent of the interviewees and explained beforehand via email that the results of the thesis would be anonymized for participants' privacy. The verbal consent can be veriﬁed with the researcher in the transcripts and recordings. The researcher has stored these securely, and they were not included in this public thesis to main interviewees’ privacy. In case asked, the researcher can provide a sample written consent form. Research results were reported anonymously by omitting names and titles (only categories of general roles were reported). The researcher asked interviewees if they could be recorded for the use of this research. One of the interviewees preferred not to be recorded; as such, that interview was not recorded. It was mentioned that interviewees did not have to answer any question that they did not want to. However, there weren’t major subjects that the interviewees said they did not want to talk about. None requested to read the results in advance. In the assisted process analysis method, the same verbal consent was obtained from participants for the narrative interviews. In reporting back the results, anonymity was maintained by not referring to their name- only “Interviewee 1” and “Interviewee 2” were used here. The participants granted permission to include the process maps in the results. For the guided questionnaire sessions, it was made clear that results would be anonymized.