Agile Bibliography

Do you have a hard time keeping track of those articles that you read and think “I could have used this when I was talking to ….?” Do you sometimes need an article to back up a point that you’re making, but don’t know where the data is? Well, I do. I’ve started lists a number of times, and keep misplacing them.

This time is different. When a discussion on one of the mailing lists got into studies demonstrating the effectiveness of Agile Software Development, I decided to start a list in a place that won’t get lost. That place is (well, was), the Agile Bibliography Wiki.

I’d really appreciate it if you’d use it too.

UPDATE: After spending untold hours reverting changes from wiki spammers, I gave up. You can find the information archived on the Wayback Machine.

No Comments

Categories: Tools and Techniques

Carnival of the Agile Conference

The new Carnival of the Agilists is focused on the Agile 2007 conference.  You’ll find a bunch of references to blogs discussing the conference.  There’s some interesting stuff.  There’s even a pointer to my good friend, Jack Ganssle, who is not an Agilist and is highly allergic to people touting a New Methodology.  Jack is interested in things that work, and work well.  I was glad to see he had some good things to say.  The reason he did, is that people talked about things they had done and the results they got from doing them.  Telling those stories works ever-so-much better than telling your theories.

I found it amusing that the first response to the Carnival of the Agilists post was one complaining that the drinking water wasn’t obvious enough, being provided in coolers instead of bottles.  All I can say is that if this is the biggest complaint, the conference was a great success!

1 Comment

Categories: Uncategorized


Pair Programming techniques

Pair programming has been widely touted as a effective means of generating excellent code in a cost-effective manner. It has also been widely reported as a waste of time or as uncomfortable. Many people reject pair programming without trying it. Others, however, still don’t like it after being forced to use trying it.

I’m convinced that there’s an art and a science to pair programming. I don’t think it comes naturally to most people. It’s sometimes easy to pick up by osmosis, but I’ve heard too many complaints about pairing to think that’s a common occurrence. I’d like to hear your real-life stories about pair-programming situations. If you don’t feel comfortable leaving your story as a comment on this blog, send them to “pairprogramming at”. Read More

How to get people to do what you want

Back in March of last year, David Maister was interviewed by Wayne Turmel and he said some amazing things. I’ve been meaning to talk about this for some time, but the work of transcribing from audio has tempted me to put it off. I highly recommend listening to the whole thing.

David Maister is a business consultant, but what he says here is extraordinarily appropriate for most of us technical people, too. He describes starting out with the same vision of success that I had, and how completely wrong it was. Read More

It’s all code

I’ve never really liked stored procedures. I always put it down to the fact that I’m a programmer, not a database person. I like keeping the functionality in the code. The database is just a place where objects go when they sleep.

My current client uses stored procedures for all database reads and writes. It probably made sense when the code was ASP, but Java JDBC code has all the expressibility you could want.

Today, I learned a new reason to not like stored procedures. Read More

Software Development is not a Commodity

Esther Schindler, a senior editor and columnist at, recently asked on the agile-testing yahoogroup,

If you could get the (client) boss(es) to understand JUST ONE THING about computer consulting and contracting, what would it be?

It would be that software development is not a commodity. The cost-value equation is not just enhanced by cutting costs, but more effectively, by enhancing value. It’s not just a matter that software is produced, but what software is produced. Does that software clearly express the nature of the business? Is it an asset that can be extended and adapted as the business grows and changes? All too often, the only measure applied seems to be the hourly cost of the software production (neglecting even the number of hours required). Too often I get the feeling that I, the consultant, pay more attention to the long-term value to the company than do the employees and executives of the company. Read More

Building Relationships

So much of life, even so much of software development, comes down to interaction with other people. And a big key (perhaps the big key) to this is building relationships. David Maister says some very interesting things on this topic–things that hit home with me. I’ve been meaning, for some time, to comment on an interview he gave on another site. While I’m waiting to get around to that, let me point you to this wonderful podcast (available in audio and video formats). Go watch it; I’ll wait. Read More


There’s been some discussion on the XP Yahoogroup about the practice of “blocking” in order to protect an Agile team in a non-agile corporation. I’d gotten rather behind in my reading, and came into the middle of the discussion. I’ve just now tracked this discussion back to a post by Scott Ambler, where he says,

This is a great example of something that I call blocking, where you produce the paperwork, attend the meetings, pretend to care, … to make it look as if you’re following the “official process”.

Scott is responding to a mention of the use of PERT on the Polaris submarine project. Scuttlebutt says that PERT was deemed a great success in managing the Polaris project, but in reality the PERT charts were reverse-engineered from more seat-of-the-pants management techniques. As the stories go, this “scientific” management technique wowed the Congressional oversight committees, and such techniques have been the backbone of government contracting oversight ever since. Read More

What is Agile?

There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.

So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.

The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.

I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. Read More