Writing software with the grain

Exploring the humanity of Agile methods

Agile software development has proven its worth from a business perspective: Agile teams produce better software faster and excel at retaining superior talent. Another aspect of Agile methodologies is lesser known, but of equal importance: they align with the grain of our humanity. Tim Berglund's thoughtful essay explores the ways three elements of most agile projects make life better for the people who work on them. If you're not already doing Agile development, this article could convert you. If you're already a convert, you'll gain new insight into Agile's success.

As a thought experiment, try to remember the last functional specification you read. (If you're really brave, think of the last one you wrote.) If you're lucky, it's been a while, and maybe you're having trouble recalling the specifics. Or maybe it was yesterday, but you still can't remember what you read. Sifting through 300 pages of carefully numbered, hierarchically organized, traceable, gatekeeper-approved prose is, after all, only marginally more interesting than hearing an omnibus spending bill being read aloud in a nasal monotone. Reading and writing spec documents aren't the most humanizing activities in our profession. Rare is the software engineer who gains a deep sense of professional satisfaction, or insight into his or her humanity, from such an experience.

Defining Agile

I use the term Agile to refer to any process that broadly follows the principles in the Agile Manifesto, not any specific methodology like Scrum or Extreme Programming (XP). Although Agile processes can be rich and varied in their details, here I focus on the fact that they often capture documentation in the form of user stories, that their documentation is lightweight, and that they usually schedule activities in brief bursts called iterations.

Of course, the hip Agile shop you work in doesn't write functional specs anymore, and that's a good thing. Your shop might have adopted Agile for any of a variety of reasons. Certainly agile methods have been the majority report among thought leaders in the Java community for several years now, as they have in the Ruby, Python, ALT.Net, and other communities. Further, case studies exist to show C-level executives why implementing Agile is a good idea that justifies the training expenses, and perhaps organizational changes and even physical-workspace improvements, too. Agile teams are more productive and can recruit and retain better talent, release features more quickly, and deliver higher quality software. Business managers are responsible for paying attention to and optimizing metrics like these -- but they are never the whole picture.

Agile is also effective for another reason that isn't necessarily on the business managers' radar: its practices align with our humanity. Agile has hit on some key insights and practices that are more consistent with common human characteristics than equivalent practices in the methodologies we call Waterfall. Agile recognizes the nature of the people whose activities it seeks to organize. It wisely capitalizes on several practices that people naturally tend to engage in, and in which we find greater fulfillment.

Going with the grain

Most woods have a grain: the fibers in the cell walls are all aligned in one direction, giving the wood a distinctive pattern and structural characteristics. Woodworkers must always consider the grain. Sometimes, as when they cut a board to length, they must cut across the grain; it takes more work and a specialized tool, but it can't be avoided. But when refining the surface of the wood by planing, sanding, or staining, they must work with the grain. The grain might limit what you can do with the wood, gently nudging the tool's motion along the lines of the wood's fibers. The material of the craft -- the wood -- imposes constraints on how the craft is executed and what kinds of results can be achieved.

Like wood, all of the tools, processes, languages, frameworks, methodologies, and communications media we use as software developers have an orientation to them. We might be able to force them all to produce similar results; all may have their own strong and weak points; and certainly all have their adherents and detractors. But none of them is neutral. When used by a competent practitioner to produce good results, each quietly nudges the development process and the thinking that underlies it in one direction or the other. For example, as Steve Yegge famously explains in his essay "Execution In The Kingdom of Nouns," Java code makes you think of things, not actions. Twitter prevents you from expressing complex ideas. Using your IDE's autocomplete feature makes your identifier names longer. To one degree or another, the medium is the message.

Many of the sensibilities mediated by the tools and techniques we use might be entirely neutral -- long identifiers might not be a problem if the whole team has wide monitors -- but some clearly are not. When we consider matching the grain of our processes with the grain of ourselves -- and the pain that results when we don't follow the grain of the person -- the matter is anything but neutral. If our work requires us to act like someone we are not, that becomes a deeply personal problem that can affect the quality of our work. Denying or suppressing common elements of our humanness doesn't consign a software project to failure, but it certainly doesn't add to its chances of success or contribute to a team's vocational satisfaction.

Agile lets us work with the grain of our humanity. Specifically, each of three elements often found in Agile projects -- user stories, lightweight documentation, and iteration-based scheduling -- goes more with the grain of humanity than its Waterfall counterpart.

1 2 3 4 Page 1
Page 1 of 4