What is the right sprint length?

Well, it pays to consult the thought leaders on this one. I’m told Ken Sipe does one-weak sprints, when he’s not busy piloting his single-engine plane deep into the bush on an obscure errand somehow related to an enterprise SOA deployment. Jared Richardson prefers a more moderate two weeks—life just has a slower pace in the South—and of course there’s a whole slew of lesser Agilists who claim you need a lavish three or four weeks to really find your stroke and make a productive team.

Of course, it all depends on what kind of project you’re talking about. Because for software, sure, two weeks is great, but if you’re taking advantage of amazing late summer weather and a few pleasant weeks on the bench to do some regrading of a troublesome patch of back yard, about two hours seems to work well.

Just saying, is all.

Comments (2)

Writing Software With the Grain

My JavaWorld article, Writing Software With the Grain: Exploring the Humanity of Agile Methods, is up! This is my first publication in anything bigger than a blog.* Dorky as it is, I’m pretty pumped!

The article explores several common Agile practices—to wit: user stories, lightweight documentation, and iterations—that happen to align well with normal human behavior given the kinds of creatures that we are. There is, you might be thinking, a host of philosophical assumptions that underlie this sort of reasoning, which I would be only too pleased to discuss over drinks sometime if you’re local.

I had to pick a limited number of Agile practices for analysis in the article, but I think there is more to the story than the three I’ve identified. A good example would be Extreme Programming’s Sustainable Pace. The opposite of Sustainable Pace is the discipline of death-marching developers just hard enough that they don’t quit, but hard enough that we squeeze maximum productivity out of them. If developers were impersonal units of software production akin to machines, this would be the right way to manage them.

The most obvious objection to this is the law of diminishing returns, or the idea that each marginal hour worked is an increasingly fatigued, and correspondingly less productive, hour. While there is certainly some truth to this, I think we’re forced to grant that we actually do make more progress when we work more hours. Everybody knows crunch time, and every honest developer is forced to admit that the crazy schedule of the final push to the finish actually make a difference—at least up until the time the hallucinations start, which in itself can be kind of fun, as long as it’s your coworkers doing the hallucinating.

The best objection to overwork isn’t a utilitarian one; rather, I would argue that the notion of Sustainable Pace is grounded in the right relationship between work and the other activities in human life given the kinds of creatures that human beings are. It is good and right for us to spend a certain amount of our time following some kind of economically productive vocation out in the commonwealth. It is also good and right for us to spend some amount of time with friends or family, some amount of time sleeping and eating, some amount of time standing in line at the DMV, some amount of time inside, some amount of time out-of-doors, etc. For most people, work might take up a plurality of the pie, but it should not be a significant majority. It is in our nature to spend our time in a variety of roles activities, of which work is but one part.

“The Humanity of Sustainable Pace” could definitely use a more detailed treatment than I’ve given it here, but my point is to illustrate that there is more to the topic than my article covers. I’d love to see the community do some more thinking along these lines. The trick is to realize that human beings are a particular kind of thing—we implement a common base class, if you will—so the practices and methods we develop in our vocation should respect that class’s semantics. The notion that we are uniform production units that can be squeezed into whatever organizational structure and management schema we choose is destructive not just to the ontology of the human person, but also to the well-being of the people on our teams—people who may well be our friends, and people whose healthy vocational context is certainly our responsibility.

So let’s think some more along these lines. Agile is doing great things, and hopefully more great ideas can follow from it.


*This is technically untrue. In sixth grade, I wrote to the middle-school science magazine Current Science with a proposed design for a perpetual motion machine, which was in essensce a really, really efficient electrical generator. They redrew my diagram and published it, asking the readers if they thought it would run forever. Widsom of the crowd, baby! Except in this case, perhaps not.

Comments (2)

Prosaically Entitled Inaugural Post

Welcome to the professional blog of Tim Berglund, founder of the August Technology Group. I’m no stranger to blogging, but this represents the first time I’ve committed to writing about software development exclusively. Since inaugural posts filled with a bunch of ambitious plans for my extensive future content, or high-minded declarations about how I’m going to “explore the medium,” or ever at any point putting in print the words, “Let the conversation begin!” are all just a wee bit 2004, let me just assume you know why I’m blogging and tell you a little bit about myself.

I’ve been developing software professionally since 1992, two years before I graduated from college. The first seven years of my career were dedicated to embedded firmware and simple Windows applications, usually the handmaidens of some firmware project or other. In about 2000, I discovered Java and web development and have not substantially looked back since—although I don’t mind admitting that debugging software with an oscilloscope and a soldering iron has a otherness to it that we are hard-pressed to duplicate in web development.

In the eight years since, I have developed internal web applications, ecommerce web applications, B2B integration software, specialized vertical search tools, and other great code living mostly in the world of open-source Java. Recently “Java” has included Groovy as often as not. This is a good development for the community and for me.

I started the August Technology Group in the summer of 2007 so I’d have a platform to serve customers more directly through execution, training, and mentoring in the kinds of software development I’ve done using the agile methods I’ve learned to apply. I’m starting this blog now so I can talk about software as the kind of thing I think it is: a fun, challenging, rewarding, deeply human enterprise surrounded by a richer intellectual tradition and more interesting intersection with the liberal arts than we often think.

Which isn’t to say I absolutely won’t post neat tips and tricks about how to do odd things with regular expressions in Groovy or how to configure Jetty to do thus-and-so. It’s just that I might wax philosophical on occasion as well. For those who know me, this is no surprise. For those who don’t know me, I look forward to making the introduction and getting to know you as well. Thanks for reading, and thanks for subscribing.

Leave a Comment