does agile impede creativity?

This commit is contained in:
Wouter Groeneveld 2023-06-24 13:50:30 +02:00
parent 4e9e8cf775
commit 73d0008c8b
1 changed files with 43 additions and 0 deletions

View File

@ -0,0 +1,43 @@
---
title: Software Development Methods That Facilitate Or Impede Creativity
date: 2023-06-24T11:45:00+02:00
categories:
- programming
tags:
- creativity
- agile
---
Dave Rupert's [The State of Agile Software in 2018](https://daverupert.com/2019/03/the-state-of-agile-software-in-2018/) made me think: can agile be detrimental to creativity? I think it definitely can, depending on how you cling to certain methods even though clearly they are meant to be a guideline, not a strict set of rules. The more strict rules a development team has to work with/in, the less motivational and more constrained the work environment becomes, up to a point where creative effort becomes the ultimate price to pay.
There's surprisingly little scientific research done regarding the relation between a development method in itself and creativity, but I did find one interesting paper by Blaskovics et al. entitled [Impact of the Applied Project Management Methodology on the Perceived Level of Creativity](http://acta.uni-obuda.hu/Blaskovics_Czifra_Klimko_Szontagh_132.pdf). They conclude:
> The results of the research suggest that the chosen software development approach has an impact on the perceived use of creativity, whereas learning is significant in cases where the stand-up tool of agile project management is used.
But what is "perceived use of creativity"? The authors perceive creativity very different compared to what I call creative problem solving in my book [The Creative Programmer](/works/the-creative-programmer): creativity is operationalized "through the degree of
innovation content and extraction in the project, as well as through factors that relate to the exploitation of creativity as the way how it is learned and recognise". What does this mean? The authors surveyed 61 project managers and employees, and asked:
- How innovative was your project?
- How challenging was your task in your last project?
- How much have you learnt from your last project?
- How was your work appreciated during the project by others?
These four components, according to the researchers, make up for a certain creativity level in projects. Then they asked which process and which tools were used during the development---waterfall or agile. Blaskovics et al. end with little fanfare: agile is more creative (because on average, projects were more innovative, challenging, learned, and appreciated).
There are several problems I can identify with this research. First, why interview project managers instead of the people that actually push these projects forward? The survey population is not clearly explained, but we all know what project managers love to say. Next, those four components are irksome, even though they're (very) loosely based on previous findings by famous cognitive psychologists Amabile and Csíkszentmihályi. I could get a lot of appreciation in one project that's an exact replica of something I did years ago: not creative. The project might be called "innovative" because we love to use that word. Why would a waterfall project not be challenging? Too much challenge, by the way, impedes creativity, as concluded by the very same Csíkszentmihályi---whoops?
I think an agile project management methodology could just as well be impeding instead of facilitating creativity, and it would be interesting to see more research digging into that. For instance, all those required meetings tend to interrupt flow---and creative work, and even though it is designed to facilitate collaboration, haven't you been in a situation where the result was exactly the opposite? Right. The strict cadence of development might be strangling your creative efforts instead of pushing them to the next level. I think that depends on the current company culture and the amount of control managers want to exert.
Usually, micro managing is done out of fear: fear that your employees aren't doing what they're supposed to be doing (typing brackets and semicolons), fear that too much talking interrupts the flow of work (while it does exactly the opposite). Most corporate environments I've worked in employed a strict lunch break: you get your thirty minutes, and that's it. One time, we were hot-fixing an important bug in production all morning and noon, and after putting out that fire, we finally allowed ourselves to take a break. But we made the mistake of playing a game of cards at 2h30 PM, which the manager saw. Guess what happened? That same person didn't see us putting out the fire, but even if he did, I don't think it mattered.
That kind of control---out of fear---most definitely squanders creative potential. More on that in [The Creative Programmer](/works/the-creative-programmer). These types of managers are encountered in any company, and that's independent of the employed software development methodology, so perhaps the researchers asked the wrong questions (to the wrong employees)?
Researchers Hodgson and Briand published related work, [Controlling the uncontrollable: 'Agile' teams and illusions of autonomy in creative work](https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=c882822e09be6103267e32db161cf6203e29242c). THeir conclusion? Agile is not the answer to creative freedom:
> While Agile/Scrum here resulted in a system where the members of Gameteam, collectively, had influence over the choice of tasks, work methods and, to a degree, quality standards, more substantial decisions related to work effort, targets, resource allocation and the selection of team members were imposed on them externally. The teams developers and leaders enjoyed autonomy, but only within a context wherein governing and surveillance mechanisms were defined and activated by actors or authorities outside the team.
That means agile only introduces the _illusion_ of creative freedom, where important creative decisions are still governed by external authorities. Of course it's still very much possible to solve the day-to-day problems as put on the swimlanes in a creative fashion: by now we're bumping against the distinction between individual, team-based, and larger forms of creativity.
In another [systematic literature review](https://d1wqtxts1xzle7.cloudfront.net/87724528/10.1007_2F978-3-642-02388-0_9-libre.pdf?1655632065=&response-content-disposition=inline%3B+filename%3DCreativity_in_Agile_Systems_Development.pdf&Expires=1687605208&Signature=XLE0gOqjJZHjokLZNWGFIZot3Uw0vfGbXEb3ZAbjNUkSbeo9mE13So29dyvRreStIpSjU4-JxBPU5DYf8pFm47AgXyufd3nkA8VxLcmwnU7xjR4BEYhdqeyMhpoFsfwbXg1lcrcoUYqK9nSK7o8TyNwZSYnT31PJm1dY9tUmxCRmHBwJset~7Gz0qxB2bZhQLD8bmpfaGOnXb92~~oH5FTHyHsA~I574LANmUTqqE8hkoAveQrO8IzrErwM7A2wZgtulS7h4zEbxDsUS7BLuRgKN5yBPcbjlB-LaLe9U0J7wOzXzpC6UmqnOZ4xq0zrdlgjRBlXwRcQCN8Q0xHMn0w__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA), Conboy et al. find conflicting evidence that on the one hand claim agile methods foster and drive creativity and on the other hand totally impedes it.
What to believe then? Perhaps it's important to remember that it can go both ways. The development method is just one factor of the many that influence creativity, as creativity is _systemic_. Hopefully, by the year 2023, we're beyond introducing agile (or microservices for that matter) just because it's the holy grail that will solve everything.