Agile Software Development

IT Conversation

Audio clip I

We value individuals and interactions over processes and tools. The idea there is, uh, you know, it’s funny, if you look at the arguments in the Agile world, they’re all over process, the XP process, the Scrum process, the Crystal process, whatever. So we do talk about process, and we cherry-pick our tools very carefully. And I just wrote an article for Crosstalk Magazine on the Agile toolkit; cherry-pick them very carefully, want them very pointed and very efficient with clearly demonstrated value and so on. But, when we get down to it, the heart of what makes a good project work is not just the individual people that you have there, but the way in which they interact with each other. So we highlight individuals’ interactions and so we talk a lot about collocation, collaboration. I talk a lot about morale, amicability, community. If you go to the toolset, now you want collaboration tools that allow multiple modes of communication, you want sound, you want video, you want archiving, you want online chat; you want all of these things at the same time. So you’re watching it; there’s a lot of workshopbased activities in Agile Development. Planning is not done by the project manager sitting alone in a room, but it’s is done by the entire group of people who, whether it’s coarse grain or fine grain, you’re looking at the set of things that need to be done and jostling each other either to think of something new or to change their estimates or suggest solutions or something like that. That’s done in design, also. There’s pair programming, there’s all sorts of things, but the emphasis is very, very strong on increasing, if you will, the brain-to-brain communication.

sound

Audio clip II

Customer collaboration over contract negotiation. So, yeah, there’s a place for contracts, not to pretend like you can’t ever do contracts, but even better than a contract is if everybody gets on the same side of the table and they work together. So this idea of collaboration not just within the team, but collaboration across organizational boundaries, in particular with the sponsors and end users, then you can actually optimize, for instance, the requirements. You could discover that the requirements as written aren’t what the people really want. So now if you’re out here in a contract situation, you have to talk about changing the contract. If you’re in a customer-collaboration-system situation, you can work together and decide whether to make a change in the requirements or not. That’s customer collaboration.
sound

Audio clip III

Responding to change over following a plan. So while we all agree that planning is a useful activity, the plan rarely survives, sort of, three days into the project. It’s most of the time between three days and a week after the plan is built, it’s out of date, something’s happened. And so this responding-to-change idea is what I call paying attention to current reality. You come into the project one day – you know, whatever you’re faced with, it could be anything - we don’t get hung up on, say: well, but the plan said something; we go, hmmm! Okay, so what’s the best thing to do now in the current situation? Do we, in fact, follow the plan or do we change the plan, or what do we do? So responding to change over following the plan actually has an implication that we do a lot more planning, but we do it collaborative, quick and either typically short-time horizon, fine-grained and sometimes long-time horizon coarse-grained, if that makes sense to you

sound

Audio clip IV

Alistair Cockburn: And ‘adequate’ now becomes the question. So what would be a barely sufficient amount of documentation? When would it be done? What would it look like to help the future people come on? That is a really tough question, it’s a really ugly one and, typically, people don’t do enough. So I’m looking for really inexpensive ways to do this, and I think white-board photos, videotapes of designers discussing at the white board, that kind of thing, may give us a handle on getting this.

Doug Kaye: That also has the advantage that it captures the intent of the developers, which sometimes can be more valuable than the actual code. After all, the code is there.

Alistair Cockburn: Classically, classically impossible to catch. I don’t know how many research projects I’ve seen where they have as an intent to find a way to capture that. But if you have, for instance, somebody from the team who’s got the software and somebody from a different team who doesn’t know the software, and they take some aspect of the system and they go over the design for it, what’ll happen is the person who knows the design will say, “Well, basically it works like this”, and sketch some stuff out. And then the other person will interrupt and ask questions, “Well, why not this, and why not that, and what about this, and what about that?”, just as the newcomer developer would want to ask, too. And then the conversation gets more convoluted and complex and deeper as they go. And if you have that all on video tape, then in a sense you’ve got this very rich conversation into the future that you can archive.

sound