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.

Thought Transference

Thought Transference

I’ve written before about being a visual thinker, but a presentation by a colleague of mine this morning at work set me thinking about it again. I won’t go into the detail of his talk which was based on this talk at ACCU 2013. Suffice to say that he has a strong interest in understanding thought processes as they relate to software development in particular.

There are different styles of thinking. Some are visual; some are language-based. Some are grounded in rationality, others take soaring flights of fancy. A person who thinks in a particular way will find it difficult if not impossible to imagine how somebody with a different cognitive style thinks: I am completely unable to imagine thinking in words.

Most people appear to use a combination of verbal and non-verbal thinking. Purely non-verbal thinkers are a minority, although they are reportedly more common among the autistic population. Indeed one of the best known autistic women, Temple Grandin, is a purely visual thinker. She wrote this informative article about her own experience.

When considering cognitive styles I encounter this conundrum: how can a purely verbal thinker imagine concepts that transcend language? How can they hold something in their mind that they lack the vocabulary to describe? I do not know the answer to this.

Language is a tool for communication. It allows something to be transferred from one mind to another, but the process is imperfect, incomplete. It’s like emailing a photo of a scene, reducing all the sensory impressions and feelings to a collection of colored pixels. So much context is lost.

How can I describe a walk through woodland? I could take a picture, freeze one instant. I could describe the feel of the ground underfoot; the earthy, damp smell; the sound of the wind through the leaves overhead overlaid with the songs of birds and the zip and hum of insects; the play of the dappled sunlight through the canopy onto the undergrowth. I can see that walk in my mind even though I never experienced it directly in that exact form. But can I conjure those same thoughts in your mind?

Much of what I hear or read has an emotional impact that derives from my own experiences, my own personal set of likes and dislikes, my own moral sense. Shared culture means that there will be overlap between people depending on how much they have in common. But ultimately what I experience inside my own head is unique to me.

Which leads me, in a round-about way, to another attempt to use words to build a mental model in your mind of what it means to “think in pictures”. Even that phrase is misleading: perhaps I ought to call it non-verbal thinking. Because what I “see” is not just like an array of photographs.

Consider a simple mechanism like a door hinge. Suddenly in my mind I am holding a 3″ steel hinge. I am feeling the weight of the cold, hard metal; I am opening and closing the two halves, feeling the friction in the joint; I am seeing how the screw holes — three per side — are arranged and their edges countersunk. I am fitting such a hinge to a door, seeing the process of first removing the screws, removing the old hinge, aligning the new one in its place and then driving the screws in to hold it there.

Visual thinking, for me, is also spatial and temporal. I see objects in relation to each other, and I see how the objects and their relationships change over time. The models in my mind are not static but dynamic. Communicating them to others is difficult: it requires the use of visual metaphors and analogies to “real” examples. My visual representations must be translated into language. When speaking or writing that is typically English, when programming it would usually be C++. The process is the same, and over the years has become largely intuitive.