Why I Don’t Do Agile (Software Development)

Why I Don’t Do Agile (Software Development)

Agile software development is a collection of methods for organizing software development teams and their work. There is an emphasis on interaction and feedback, and these methods have proved to be successful when adopted by companies. But it’s not for me.

After such a blanket statement I need to explain what I mean. There are many, many aspects of software development encompassing roles from business analyst to programmer to project manager and beyond. I’ve been a professional developer for nearly 20 years and personally have no interest in any of the roles outside my own: they exist only to facilitate my work by reducing the points of contact between myself and the larger world.

Over time I have evolved a way of working that fits well with my strengths and accommodates my weaknesses. I do best when I have a clear goal, an environment free from aural, visual and tactile distractions, and the minimum of interruptions. In essence it’s a case of winding me up, pointing me in the right direction and letting go; then standing back until I get where I’m going (or the spring winds down).

This works for me because it allows me to enter a flow state and remain there, my mind focused on the task at hand. This is the state in which I am most productive by far, completely in tune with what I’m doing to the point where there is no conscious effort.

This is at odds with some aspects of Agile methodology, in particular its emphasis on team interactions. I spend the majority of my time working on solo projects and don’t fit within any single team along organizational lines. This makes my inclusion within any single team arbitrary; in fact I can’t even remember the name of the development team I’m supposed to be in.

The communication requirements have a disproportionately negative effect on my productivity. I dislike daily “stand up” meetings where I have to listen to incremental updates from the other developers in the team. It’s like enforced socialization, and it might as well be meaningless smalltalk because what they have to say is mostly irrelevant to what I’m working on and hence of no interest.

A meeting is a distraction; it’s like a pothole in the road of my smooth progress. I’m aware when it’s approaching, so I can’t focus fully on my development in the time leading up to it. Participation diverts my thoughts from their work pattern and it’s as if the mental images I’d been constructing fade and disappear. All the work I did to build them is lost, and I have to spend a significant length of time just getting back to where I was before the interruption.

If you’re part of a team that uses these methods you’re expected to be involved in all of them. I have conflicting needs when it comes to communication: I function at my best when I have control over when and how I communicate. In practice this means short one-on-one interactions when I need some information, and non-verbal communication for things like progress reports so I can just post them some place where anybody concerned can read them without directly contacting me.

The problem I have with Agile software development is that every incarnation I’ve encountered has been a one-size-fits-all suite of buzzword-heavy methods, the majority of which are well-established working practices with new names to make them appear innovative. There is undue emphasis on the methodology as opposed to simply getting the job done. I’m strongly in favor of effective working practices and I actually use many of the methods collated under the Agile banner. But I don’t call the way I work “Agile”: using a wok doesn’t make your meal Chinese.

2 thoughts on “Why I Don’t Do Agile (Software Development)

  1. Yes, I’ve been wondering myself about how much I’d want to work in that. (and how it would work for autistic people in general)

    In a way the daily stand up meetings are a low barrier way to just throw every slight problem out there, which is good for me, because I can spend a long time (too long) mulling a problem over, not wanting to contact someone about it yet.
    But yes, enforced socialization, all having to hear all information about everything that’s going on… pfffff…..

    In a way I like the short cycles where it’s clear where you’re going in this sprint, and park everything else for the next sprint. It can make things more easy to overview, short term deadlines, concrete tasks. But it’s also chopchopchop changes all the time.

    I definitely see your point about the flow, just being able to work on something until it’s finished. Then again, a big problem here can be that you might be going in the wrong direction, if there no monitoring/communication in between, which is one of the reasons Agile was developed.

    And in general: there’s so much management bla and trendy babble, making it sound interesting, but not actually improving much. It’s very much like what is called in the NL, “Het Nieuwe Werken” “The New Way of Working”: more flexible workplaces and everybody being able to work from everywhere, in the cloud, on different devices instead of desktops. It can work, sure. But in most implementations of it, and for most people who didn’t ask for it, it just creates more chaos, more hassle and more insecurity. It seems more about appearing to be modern than actually adding anything.

    Sorry about the novel 😉

    So is your company working more and more in this way?

    Liked by 1 person

    1. No need to apologize. You raise some interesting points for discussion, so I’ve penned a novel in response 😉

      A couple of the development teams where I work apply Agile methods fairly consistently — that’s where the daily stand up meetings come in — but after giving it a go a few times I opted out.

      We have seen some tangible benefits from continuous integration with its automated testing, and from shorter, time-constrained development cycles (“sprints”); however we struggle to keep the main branch of the codebase stable because it’s a huge amount of code and most of it doesn’t have any automated regression tests. (There would literally be years of work involved to add them in at this stage, so that’s not going to happen.) There’s also a problem in that bugs found by our testers often have higher priority than our work in the current sprint, so it’s not uncommon for timescales to slip. It’s a case of using the terminology but not applying the methods completely.

      The way I work is compatible with sprints: I break the project down into phases with incremental delivery of features. I don’t think of this as “Agile” though — it’s an instance of the stepwise refinement described by Niklaus Wirth in his 1971 paper published in Communications of the ACM, so the basic idea’s older than me!


I'd love to hear your thoughts on this.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.