Free Project Management Software

It seems to me that the true test of an individual’s belief in what he or she does is whether or not they would do it for free. Well, if you’ve ever wondered about how much a Scrum trainer believes in Scrum, InfoQ has just published a story on how a handful of trainers have put their money where their mouths are. According to agile reporter Mark Levison, a number of Scrum trainers have decided to make Scrum training, including ScrumMaster Certification, available to folks who could not otherwise afford it. CST Tobias Mayer has launched a program called WelfareCSM, which does just that. Likewise, three CSTs—James Coplien, Danube’s Dr. Dan Rawsthorne, PhD, and Alan Cyment—recently traveled to Serbia to provide free training to professionals who live in an area that doesn’t see too many CSM courses offered. In support of that effort, the Scrum Alliance even covered travel and other expenses.

In all, it was just a great and inspiring article that shows how much a few Scrum trainers believe in what they do.

Late last month, the Software Education SDC was held in Melbourne, Australia and Wellington, New Zealand. During the conference, Ivar Jacobson—who pioneered Use Cases, UML, and RUP—stated that agile needs to get “smarter.” Key to his criticism was the software industry’s tendency to jump on fashionable trends. To illustrate his point, he broke down the industry’s techniques du jour for the past 15 years like this:

• Fifteen years ago it was all about OO
• Ten years ago it was about components, UML, Unified Process
• Five years ago it was about RUP and CMMi
• Two years ago it was about XP
• Today it is about Scrum

Longtime readers know I’m an advocate of Scrum, which is the agile method that my team uses. I really see how it improves processes and gets our team to do things we didn’t think we could, so I hate to think of it as a fad. Certainly, its popularity has skyrocketed in the last year or two, but isn’t that due to its real potential to transform the way organizations approach software development? And aren’t all of these “flavors of the month,” as Jacobson suggests, part of a more macro-evolution in software development that extends well beyond agile? That is, as we discover new ways to work more effectively—or “smarter,” as Jacobson says—those new ways naturally displace the less effective methods that preceded them.

So is the history of software development over the last 15 years really a matter of faddish techniques and processes going in and out of fashion? Or is it simply a necessary evolution toward optimal working methods? You can read all of Jacobson’s concerns and suggested solutions at InfoQ.