Why software developers (quite honestly) hate Agile
A few years ago, I wrote an article that detailed the differences between various Agile methodologies. The article was republished by DZone.com, and got this comment (among others):
Shortly afterwards, I stumbled on this Reddit thread titled, “In a nutshell, why do a lot of developers dislike Agile?” In the thread, many developers expressed their “feelings” towards Agile. Here are some highlights from that discussion:
Highlight 1: Agile = arbitrary goals and unrealistic deadlines.
Highlight 2: Agile = “red tape” and no room for developer creativity.
Highlight 3: Agile = rushing developers to do their job.
So, what exactly went wrong with the Agile movement? Wasn’t it supposed to be about “people over processes” and eventually eliminate all bureaucracy and middlemen?
What happened to Agile
Robert C. Martin, one of the people who charted the original Agile Manifesto in 2001, has a lot to say on this topic.
When talking about the history and the future of Agile, he pointed out that Agile – the way it was originally envisioned by Kent Beck and other creators – has long been hijacked by an army of certified Scrum masters and businesspeople who do not understand how software is made (much like a city kid does not understand how a potato becomes chips).
[Agile] certification turned into this “siren song,” and it attracted, frankly, all the wrong people. Agile was developed by technical people. It was a creation of the software industry – PROGRAMMERS sat in that room and created the Agile Manifesto and the Agile principles. And then came certification. And with certification, hordes and hordes of project managers started to get certified. And they would sit for two days in a class, and get a piece of paper, and feel that it was somehow significant. And they, literally, took over the Agile movement… The Agile movement shifted dramatically towards the project management side.
So according to Robert C. Martin, Agile was originally created for programmers by programmers. But it has now gotten off track. There is now a counter-movement that emerged after the split (when the original idea of Agile got tainted by thoughtless management). This counter-movement is Software Craftsmanship, and it has its Manifesto, too.
Apparently, it tries to go back to the original promise of Agile, which was, according to Kent Beck, to heal the divide between business and programming. It also strives to fix what Agile broke – namely, it urges developers to deliver not only “working software,” but also “well-crafted software.” Which brings us onto the next important point here …
Cherchez la technical debt
Please pardon me my Franglais. What I’m trying to say is – look for the technical debt as the root cause of the problem of what went wrong with Agile. Here is a comment to one of the recent articles that criticizes the approach:
Robert C. Martin called out the technical debt problem at another conference, too (emphasis added):
You need something that keeps you CLEAN, ‘cause you need something that keeps the code from rotting. How many developers do we have in the room? How many of you have been significantly slowed down by bad code… generated by a Scrum team going too fast? When you go fast and you are focusing on getting stories done, and stories done, and stories done, and stories done… the code can ROT just as fast as you are moving. And so what happens after a year is that the rate begins to slow. Not because you’re working less hard – you’re putting in a hell of a lot of effort – it’s just that you can’t force the code to accept the next new feature.
Now, no programmer in their sane mind wants to write bad, sloppy code. Yet that’s what they are often forced to do by business folks who want new features delivered ASAP. So eventually, the team cannot move as fast as it used to.
Do project managers/Scrum masters/Agilists understand this? Some do. But many don’t. Hence, it is the developers’ responsibility to bring up this question with their managers before their sloppily-written “spaghetti code” kills someone.
Of course, not all software has the potential to seriously hurt people (thank goodness!). But collateral damage is also possible. Once, when I was still with this telecom company, a woman called customer service and complained that, because of the bad connection, she couldn’t order some important medicine that she needed.
So, in an ideal world (and if you want to be doing Agile “right”), developers should be given enough time to clean up/refactor and thoroughly think out features, so that to make the software maintainable in the long run.
Can we make Agile great again?
Agile has been around for nearly two decades. There are plenty of case studies which demonstrate that it can improve one’s process and software quality: Cisco got a 40% decrease in critical/major software defects and British Telecom was able to shorten its delivery cycle from 12 months to 90 days, all thanks to Agile.
You may say that, perhaps, larger companies have the resources to explicitly manage technical debt, and smaller firms don’t. So, here is the trade-off that everyone has to make eventually (which is also the morale of this post) …
There is no substitute for hard work.
I’m sure many of you are familiar with this viral video about drawing a Spiderman at different speeds. It could be a metaphor for the kind of software you get when you rush developers too much.
So, can Agile re-embark on its original mission of bridging the divide between business and programmers? I guess it can happen only if we start paying attention to the unnecessary bureaucracy that’s going on (in some places) and the technical debt that keeps piling up (on some projects – I’d hate to generalize). And if Agilists don’t, perhaps the Software Craftsmanship movement will do it.
TL; DR
Many developers have been voicing their concerns about Agile being broken lately. Among them are prominent figures like Robert C. Martin and Kent Beck – two of the people who charted the Agile Manifesto. Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt; frameworks like Scrum are just “red tape,” which they were never supposed to be; programmers are asked to commit to arbitrary estimates and deadlines and never get the time to think thoroughly about the features they’re creating. So if we can acknowledge and work on these problems, perhaps we can fix Agile.
Image credit: sportsmen running a sprint by Bernd Hildebrandt.
Related Blogs
Real benefits of adjoining DevOps culture to your Agile processes (supported by hard numbers)
LEARN MORE
Is it worth it for a programmer to take on a management role? (Talk by Evgeni Vintik)
LEARN MORE
