Agile Software Development for Non-Profits

"When the road bends, you cannot walk straight." It's an old gypsy proverb. I ran into it as the epigraph to Gypsy Caravan, a great film by director Jasmine Dellal, documenting the six week U.S. tour of gypsy musicians from all over the world. But it's also the secret of effective technology project management. When I first started out building software, one of the books I read was Tony DeMarco's Controlling Software Projects. It helped me understand the real forces that lead developers and other stakeholders to underestimate timelines and generally plan poorly. But somehow, (maybe it was the title) it left me with the feeling that when I got really good at this I'd be able to map out the path of a project in advance and steer it right in, exactly as imagined. All we needed to do was perfect our techniques at requirements analysis, estimation, coding, testing, deployment, training, documentation, and coffee-brewing. But it seemed that no matter how hard we tried on each project, the road always took an unexpected turn somewhere. At testing time the clients suddenly thought of an unanticipated set of requirements. At training time, a horrible bug surfaced. On the day the client was going to deploy, their network was brought to its knees by a virus. No matter how hard we tried to control the process, something went wrong that forced us to regroup. Gradually we were forced to surrender to the reality that significant software projects were always going to take us by surprise now and then. Others have discovered this too, and it's led to the approach referred to as Agile Software Development. Agile development recognizes that the road is going to bend - indeed it is rarely going to be straight. So agile methods stress responding rather than controlling. For example: We used to try desperately to assure that during training no bugs would be found and no specification changes would be offered. It was futile. Training rooms, with ten novice users banging at the keyboards are in fact perfect software testing labs that will inevitably find some lurking defects. And a roomful of your staff getting their hands on the new software for the first time are bound to come up with some new ideas. The fact is there will almost certainly be change requests and problem reports during my training sessions. So let's learn to manage them wisely. Today, at the beginning of a training session, we put up two flipcharts -- one to record any reported problems, and one to park any requested change or enhancement. These items can be acted upon later, but by capturing them here, we have turned what used to be a disruption in the training into added value that moves the project on, around the bend. In a way, all the repeatable improvements we've made in our methodology are no more than this -- to anticipate the unavoidable bends in the road, so we can take them at speed without leaving the roadway. Image originally posted as http://www.flickr.com/photos/improveit/525851663/in/set-72157600298986170/