Whenever I go to a conference I run into people who make software so differently than I make it. I also run into people who do the same things I'm doing, but they have a name for it and I don't. Someone asked me recently if I "did Agile." I always answer that we're not "formally Agile" which frankly I find very funny. We do have a client though, for whom we ship a new release every month. They ask for things (typically with emails) we design and estimate, together we draw up a list of what will be in the next phase and when it will release, and then we mostly do that. I say mostly because sometimes over the month they change their minds, or their customers impose a business change on them, and we tweak the list a little, but just about every month they get a refresh and their software has evolved to meet their new needs.

So there are plenty of people who will tell me, since I ship every month, I'm Agile. I guess so. But we don't do scrum. We don't do burn lists. We don't do pair programming. We don't have a daily anything. We manage all this with TFS and with a Word document called "phase 13 as approved.doc" that has a table in it listing work items, their descriptions, and their status. We don't really use any of the deliverables or artifacts that are considered Agile today.

So, with that mindset (what makes you Agile) I have two links for you.

First, http://martinfowler.com/articles/newMethodology.html. This is Martin Fowler on agility, the essay he first wrote in 2000. It talks about how requirements change, how people are not all the same, how customers adapt, and so on. To my great surprise it lists the Rational Unified Process as an Agile technique. His conclusion is a damn good one:

So where should you not use an agile method? I think it primarily comes down the people. If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular I think that this means you should never try to impose agile working on a team that doesn't want to try it.

Second, http://www.agilemanagement.net/Articles/Papers/CMMIandAgileWhynotembrace.html. Unfortunately the paper is only available as a PDF, but this page has a link to it. The abstract:

Agile development methods and CMMI (Capability Maturity Model^® Integration) best practices are often perceived to be at odds with each other. This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using both and exploit synergies that have the potential to dramatically improve business performance.

OK, so it isn't written in a conversational style, but you know, it makes some really good points. I've just started a project in which we're using the CMMI templates for TFS, just to see what it's like, and we're being our usual "get the detailed requirements and do the design at the last responsible moment" on it (we have sensible phases which makes this possible) and you know what? It's working pretty well.

So, you think you know your methodologies, but I recommend you read both of these papers and then see how you feel. You may be surprised. You may be pleased (I was.) And you may start working more effectively.

Kate