Agile Learning

We use an agile software development methodology called scrum in our IT department. Our consultants from Microsoft and Neudesic introduced it to us and I've become a big believer in it. I like it for a lot of reasons, but mostly for two:

1. Responsiveness to Users: Agile methodologies emphasize a quick turnaround between gathering requirements and getting a product in front of the users. I've found that there is nothing better than having a smart group of people beat up a prototype that we've worked on. Painful at times, but writing reams of documentation does not create good software. The only thing that creates good software is writing code while listening to the users.
   
2. Teamwork: The methodology uses a daily meeting - called the scrum - where each member of the team reports on what was accomplished yesterday, what he/she hopes to accomplish today, and if there is anything blocking progress. The meeting is limited to 15 minutes so it does not become a big time sink. It emphasizes teamwork and accountability and I've seen it in action now for about a year. It works great.

The idea behind most of the agile software development methodologies is that the traditional method (know as waterfall - see this site for a parody) was too rigid and doesn't model how the real world works.

Kathy Sierra, one of my favorite bloggers, has written a very thought provoking article where she mentions the need for Agile Learning. She points out that recent studies are showing that the skills that are taught in mathematics, science and engineering classes are not the skills that are needed in those occupations. It's good stuff and has provoked a flurry of comments. Check it out.