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.