I found two excellent lectures on IT Conversations that I would like to recommend to people looking at how to learn (or justify) agile development methods. The first lecture was given by Ken Schwaber, the creator of the Scrum project management methodology, called You Thought it was Easy: Wrestling Gold from Today’s Software Projects. In this 40 minute discussion, Ken explains what Scrum is and how it works. Its a very informative lecture that has helped a lot in giving me additional ways to try to explain the advantages of Scrum as a project management methodology.

One of the interesting points that Ken brings up is that when you introduce an empirical model like Scrum, all of the things that have been wrong in your environment for such a long time come to the surface and have to be dealt with. We have definitely seen this in our environment and it has caused some discomfort on the team. For me, its very nice to have a lecture like this that I can refer team members to that explains that this is a normal part of the process. It is, however, extremely difficult to explain to some that the problems we are seeing have been around for quite a long time, but that we have been unable to quantify them until implementing Scrum.

The second lecture was given by Scott Ambler and is called Are you Agile or are you Fragile in which Scott tries to explain the advantages of Agile methods and answer some of the arguments one would get in justifying using Agile methods on actual projects. There are a couple of interesting things about this lecture. First, he runs it as an agile project, eliciting “requirements” or topics from the audience and having them prioritize them. Secondly is the passion in which Scott talks about Agile methods and his no nonsense way of explaining the advantages.

This lecture gave me a great quote that stuck with me. “A new requirement is a competitive advantage – if I can act on it”. I found this to be a brilliant reframe of the common objection to changing requirements that happens on teams which have been “raised” on the waterfall type of approach where requirements are finalized and cannot change without having been “wrong” in the first place. This lecture is a long one, weighing in at one hour and 55 minutes.

For those teams out there that are attempting to implement agile methods in an environment that has been historically waterfall and “predictive planning” based, these two lectures are definitely something you should check out.