A common challenge within the IT management right now is to understand the implications of agile software development.  A critical step to understanding agile development is to observe an actual Agile team in action and see the results for yourself.  Unfortunately there is no official criteria for determining whether or not a team is Agile, and worse yet there are many "code & fix" teams claiming to be agile.  I often run into traditional IT professionals that are confused about Agile either because they mistake code & fix approaches for Agile ones.  Worse yet they then propagate their misunderstandings to others, compounding the problem.

At the time of this writing there is no official definition of what Agile is, and many people want to use the values and principles of the Agile Manifesto as the definition.  Although I respect this opinion, and wish it were that simply, my observation is that the values and principles are too vague for determining whether or not a project team is taking an agile approach.  When I "evaluate" a project team, here's what I look for:

1. Is the team is taking a test-driven approach to development?  With test-driven development (TDD) you write a single test before writing just enough code to fulfill that test.  This can be done at the requirements specification level as well at the design level.  I will ask a team to show me their test suite.  I want to see it run, but anyone on the team, and I want to see the actual source code.  I typically look for a roughly 50-50 split between testing code and production code, although 60-40, or 40-60 is also reasonable depending on the situation.  If I see an 20-80 split then I know there's a problem.  There are no hard and fast rules, of course.
2. Are stakeholders active participants in development?  Your project stakeholders can and should actively participate in the development process.  Minimally stakeholders should be involved on a daily basis, they should provide information in a timely manner and make decisions in a timely manner.  I should be able to ask the team to introduce me to their stakeholder(s) and they should do so right there on the spot, or at least respond with something along the lines of "that would be Beverley, and she's in a meeting right now and can't meet with you until 11am."
3. Is the team is producing high-quality, working software on a regular basis?  The team should be able to show me the working software that they've built to date as well as the source code.  The code should be consistent because it will have been written to conform to a common set of guidelines and the team will refactor whenever appropriate to ensure that it remains of high quality.  If it is early in the project, say the first week or so, then I wouldn't expect to see much.  If they're at least a few weeks into the project then I would definitely expect to see some software.  If the team is several months into the project then I would also expect to see evidence of a track record of producing working software.
4. Is the team is working in a highly collaborative, self-organizing manner? Agile teams employ the most effective communication strategies available to them, this often means that they don't write detailed specifications and throw them over the wall to each other, and they plan their own efforts instead of having a project manager do it for them.

You might find my articles Examining the Agile Manifesto and Agile System Development Lifecycle (SDLC) to be interesting introductions to agile software development.  Also, my 2007 Agile Adoption Survey provides some insight into the how Agile is being adopted within organizations.

My Agile Books

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.