Agile needs to be implemented in an agile way

#AgilePlanningAndLearning #AgileWorking

This mini lesson discusses the paradox of the appropriation of the term agile working, and gives a call-to-action for urban planning practitioners considering this way of working. Are you not yet familiar with an agile way of working? We recommend you first familiarize yourself with it here.

For all the potential of the ideas behind an agile way of working, there is no shortage of issues with trying to implement them in practice. In many cases, agile is ironically implemented in a non-agile way. Let's take a look at an example of one person's experience (from an online discussion):

Source: https://news.ycombinator.com/item?id=5406384 (paragraphs 1-4)

This person is clearly frustrated, and there are a few things I want to look at here.

First, the "hoards of money grabbing snake oil selling evangelists": while the language is clearly an exaggeration, it refers to a serious issue agile has had during its growth in the software industry. Agile working is being sold as something that you can buy from a consultant to improve your productivity.

This person has likely been prescribed a way of working which became rigid and ironically not agile (even if it was labelled as such). Another perspective (paragraph 14 of link) on this is: "If Agile has failed, it is because of its success. As soon as smart Agile development teams started delivering good results, companies started coming up with tools to help others do it right. Businesses could buy into the illusion that Agile is a tool you can buy, and vendors were happy to profit."

Second, the person says to "start applying critical thinking". However, an agile approach is essentially critical thinking. Oxford University Press's Lexico dictionary defines critical thinking as "the objective analysis and evaluation of an issue in order to form a judgement". Analysis and evaluation (and then iteration) are core parts of an agile approach.

Third, they mention "stakeholders making implementation decisions in ivory towers". This is both really unfortunate, and not "agile". Instead, in this way of working information should drive decisions, not a work hierarchy.

One of the characteristics of agile organizations: information drives decisions, not a work hierarchy

Lastly, they describe people that "obsess over the minutiae of how to implement scrum, retrospectives, and sprints". What is "Scrum"? It is a prescribed way of working that claims that if you follow its roadmap, you will be agile. Ironically, when you over-focus on implementation details such as described, you are not focusing on people and interactions over processes and tools (first characteristic in the table describing agile organizations above). You are also not flexible (6th characteristic) and will likely have trouble being responsive (2nd characteristic). If you are forcing these implementation details on others, you are probably not embracing conflict and discussion (11th characteristic).

---

In summary, this person online had a highly negative experience with a way of working that was labelled "agile". Whatever it was intended to be, because it was not implemented in an agile way, it is not agile working.

Sadly, misuse of the term and distortion of the approach such as this seems to be anecdotally common. And as such, agile has become a word with very negative connotations, or one that for some people has lost all meaning.

In urban planning, the rise of tactical urbanism and the need to increase the pace of a transition to sustainable cities suggest that the ideas behind agile are gaining popularity in the field. As urban planning professionals, we need to be wary of negative implementations and methodologies that end up contradicting these principles. I propose we take an active role so that the same thing that has happened to "agile" in the field of information technology does not happen in the field of urban planning as well (regardless of the different language we may adapt in our field). Thus: we need to focus on the ideas, not the buzzword.

I don't advocate for or against using a specific methodology (which to note, one may have been forced upon the person in this example); you have to use what works for the context of the team. What you should be careful with in using a methodology is not to get lost in it and forget about why you're using it in the first place.

For those that wish to take up this way of working within an urban planning organization, in order to be successful and help urban planners better serve citizens while spending less time and money on projects, agile must be implemented in an agile way. In fact, "by paradoxically following a nonagile approach to becoming agile, organisations are unwittingly undermining the success of their transformation" (Morris, 2015, p.2).

---

Want to learn more about agile bicycle planning? Enroll in our online course, and check out our other instructional offerings.