I am sharing what I found in my master's thesis in parts broken down from the research questions. This seventh post brings the research together and states conclusions. See prior parts here: 1, 2, 3, 4, 5, 6. See the full thesis here. Need some background on what agile means? See here.
Blog post 7: Bringing it all together
So... agile in planning departments?
YES! It is possible and parts of it are already happening in the Bicycle Program of the Municipality of Amsterdam. BUT... there are some nuances to consider.
The ideas behind agile transcend disciplines, 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 Bicycle Program of the Municipality of Amsterdam already excels with frequent collaboration and information driving decisions, but gaps remain in responding to change and simplification. The Alexanderplein project showed how an iterative project strategy can work together with research and analysis to maneuver many stakeholders and a large organization. There does not appear to be a “silver bullet” solution to making planning departments agile, and in Amsterdam's case, organizational structure and top management support were the most significant barriers to overcome for agile working.
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. This connects back to the theoretical roots of agile and iterative problem solving. When you get past the agile buzzword, the ideas of learning, problem solving, and continuous improvement are powerful.
If you are working in (with) a planning department, what can you take away from this?
Actionable items are as follows:
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.
Look for and test (partial) solutions The pattern language and bicycle user experience concepts can help to focus on people and interactions over processes and tools, but what are other potential solutions? Identify and experiment with ideas that lead to a more agile way of working. These ideas may already be happening in a workplace, or they may be new ones. Agile working does not have to be an all-or-nothing affair; even a partial agile way of working can bring benefits. In short, move towards agile in an agile way.
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.
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.
References
Gifford, J. L., & Stalebrink, O. J. (2002). Remaking transportation organizations for the 21st century: Consortia and the value of organizational learning. Transportation Research Part A: Policy and Practice, 36(7), 645-657. https://doi.org/10.1016/S0965-8564(01)00028-3
Nerur, S., & Balijepally, V. (2007). Theoretical reflections on agile development methodologies. Communications of the ACM, 50(3), 79-83.
Update: since this blog post was written, an academic article has been published on the thesis research (see here, open access).