• Trey Hahn

Agile needs to be implemented in an agile way

For all the potential of the ideas behind agile, 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": this is a serious issue agile has had during its growth in the software industry. It 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 (see 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". The ironic and sad thing here is that agile essentially is 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 very much agile.


Third, they mention "stakeholders making implementation decisions in ivory towers". This is really unfortunate. Information should drive decisions, not a work hierarchy.


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


Finally, they describe people that "obsess over the minutiae of how to implement scrum, retrospectives, and sprints". Scrum is a prescribed way of working that claims that if you follow its roadmap, you will be agile. Ironically, when you obsess over implementation details such as described, you are not focusing on people and interactions over processes and tools (first characteristic table 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).

This person 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, due to misuse such as this, agile has become a word that for some people has lost all meaning. This cannot happen in urban planning- we need to focus on the ideas, not the buzzword.


As the ideas behind agile gain popularity in urban planning, we need to be wary of negative implementations and methodologies that end up contradicting the principles of agile. I don't advocate for or against using a 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 it 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. I'll end with a quotation from another master thesis: "By paradoxically following a nonagile approach to becoming agile, organisations are unwittingly undermining the success of their transformation" (p.2).

Get an email when there is a new blog post

Subscribe for updates