I've been a practitioner of agile software development since the term existed, starting with Extreme Programming in 2000, and then agile in 2001. But, like lots of folks who've looked into this stuff, I found that agile approaches suggested that I do things that I already was, and they seemed to promote values I already had.

It's important to remember that agile development isn't entirely new. Rather, it's a collection of sensible ways to think about and approach software development that have been emerging since the conception of software development. At the end of the day, it's not whether you're following one process or another that matters, but whether your approach successfully delivers software that people like using-and a process you and your team likes.

Different processes describe different practices to adopt and use. Many tests for good process usually assess whether you're following the process or not, which doesn't necessarily mean you're delivering software people like or that you prefer to work that way. Look at the Scrum Nokia Test for an example.

The approach I've found most useful for giving my process a routine health check is based on Alistair Cockburn's properties of successful software development taken from his book Crystal Clear. To come up with these properties, he started with teams that both were successfully delivering software and doing so using an approach they'd keep using if given a choice. He started by looking at the practices these teams used to see what they had in common. This may or may not come as a surprise, but they didn't always have practices in common. But, what they did have in common were properties-general characteristics. Looking for these general characteristics became stronger indicators of success.

So, to perform a quick properties-based health check on your current approach, grab a group of your team members, sit down together in a room, and discuss these properties. For each property, ask the team to rate it on a scale of one to five-five meaning you've got lots of that property, one meaning that property doesn't exist for your group at all. Sometimes I use grade levels A through F. Then when looking across properties, I come up with a handy report card.

So, let's get started.

1. Frequent Delivery

Have you delivered running, tested, usable functionality to users at least twice in the last six months?

Software requirements are often speculative until they're actually validated through inspection and use. Value from software ultimately comes from that use. Score your project high if it delivers frequently.

2. Reflective Improvement

Did you get together within the last three months to discuss and improve your group's working habits?

Elements of a process-such as the skills of its participants, geographic distribution, and the demands of the product being created-must be tuned to match context. As the project context changes, the process must adapt. Frequent use of project retrospectives, or reflection sessions targeted at identifying process improvements, are critical. Score your team high if your team regularly reflects on and changes its process.

3. Close Communication

Does it take you under thirty seconds to get your question to the attention of the person in your team who might have the answer? Do you overhear something relevant from a conversation among other team members every few days?

Taking a long time to get questions answered or solve problems slows the team down. Even worse, proceeding with misinformation may cause unneeded backtracking. Collocated seating arrangements with the ability to make eye contact with your coworkers are ideal. Sitting close enough to get up easily and ask questions is good. If you can't see each other or easily talk, developing the habit of quickly instant messaging when a question arises can help. If questions are answered quickly within your team, score your team high.

4. Focus

Does everyone understand the goal and desired outcome of the delivered software? Do people know the top-priority items they should be working on? Are they guaranteed at least two days in a row with two uninterrupted hours each day to work on them?

Knowing what you're doing and why and having the time to do it is critical to success. In some organizations, you may know what you should be doing but have little understanding of the purpose of the software you're building and how it benefits its users. In some organizations, interruptions dominate or team members may be scheduled on multiple projects so that they have little time on any one project. Score your team high if you have clarity of purpose at the team and individual levels and have enough time to make progress.

5. Personal Safety

Can you give your boss bad news? Can people end long debates about each other's designs with friendly disagreement?

Ideally team members will have trust in each other's abilities, opinions, and judgment. The first step to building that trust is being able to speak freely without concern of political or social risk. Failure to deliver bad news out of fear keeps a project from recovering and improving from setbacks. Fear of sharing opinions can impede collaborative activities. Score your project high if members of your team can and do speak freely.

6. Easy Access to Outside Experts

Does it take less than three days from when you have a question to when an expert answers it? How about a few hours?

To understand the context that helps you make decisions about product requirements, you'll need access to subject matter experts, business stakeholders, and users of all types and experience levels. You'll need access to these people to validate prospective software designs and finished software. Ideally, access is easy and frequent. In the worst cases, you won't get the information you need or be able to validate decisions until after delivery. Score your project high if you know who your experts are and have easy and frequent access to them.

7. Strong Technical Environment

Do your developers use the configuration management system? Are your verification tests automated? Do you integrate the system at least twice per week?

To make additions and changes to software quickly requires a technical environment that minimizes risks associated with change. Configuration management and frequent code integration followed by automated regression tests reduce risk associated with change. Score your project high if your team has strong technical tools and practices.

8. Sunny Day Visibility

Does everyone on the team understand the rate of progress being made on the product? The feedback from users and stakeholders? The risks to the current delivery?

As the construction of the product is in motion, it's important to be able to see the rate of progress and how that affects plans. As we gather feedback from users, it's important that everyone understand how the product solutions are holding up to actual product use. Score your project high if anyone on the team can quickly answer questions about the rate of delivery relative to the plan and how the product actually is holding up to user feedback.

9. Regular Cadence or Rhythm

Do important process activities happen on a regular and predictable cycle?

A characteristic common to most agile approaches, including Scrum, is a regular cadence or rhythm to work. Sprint cycles are fixed in length and should start and stop on the same day each week. A daily standup meeting is held at the same time every day. Activities such as sprint planning sessions ideally start at the same time of day on each day they occur. This regular rhythm, found across most agile timeboxes and activities, is so common that many refer to it as a "heartbeat." The alternative is lots of ad hoc meetings that speckle your calendar and create unpredictable days. Score your project high if important activities are scheduled at a regular frequency and far into the future. Score your project lower if important activities are thought of at the last minute or scheduled for ad hoc times.

Now what?
If you went through this exercise, you've likely scored higher on some properties and lower on others. Start with the areas on which you score lowest and discuss what you could change that would improve things. Introduce only a couple changes at a time, make sure the whole team understands and agrees to them, and then agree on a time to come back and reassess the team to see if the changes have helped. The assessment and changes you discuss are an example of reflective improvement-the second property above.

Software development is never easy, and anyone who tells you it is selling something. Doing this sort of assessment routinely will result in a productive discussion about improving your current process. Making small specific changes to the way you do things on a regular basis will help you improve your process, the quality of the product you build, and happiness of everyone involved.