Does your software development process need tuning? How can you tell if it isn't running as well as it could be? In this week's column, Jeff Patton offers a diagnosis checklist for your team to help assess the vital statistics of your current development process.
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