O&B company training: Agile Methodology part 1

Last Saturday, we had training on Agile.  Sure, we all read and talk about Agile, as well as practice it but we haven't really had a company training on it just yet. Well, until last Saturday that is.  During that time, Butch was the main facilitator and he discussed with us the core philosophy of Agile and the practices of XP.  In the morning, we even had some kind of debate as the pros and cons of Agile vs. Waterfall methodologies.  In the afternoon, we had a game simulating a development team's interaction with customers and they have to accomplish tasks in each iteration.  We all got a chance to estimate the amount of effort needed in accomplishing tasks and we had turns in negotiating with customers.

Some of the lessons I learned from the training are as follows:
1. Agile as a methodology, could be somehow confusing to clients.
Especially if you consider fixed-price projects.  How does one go about doing things the Agile way and assuring the client that it would yield results?  There are various factors to consider and I personally thing that it's more a matter of trust between the client and the dev team so that it will happen.
2. Estimating effort takes practice.
I recall when I was a part of the ABS-CBN project team that we did have gummy bear points for the tasks assigned.  Some of us would give out conservative estimates while others didn't.  And it also depends a lot on the team's skills, of course.  Like someone would do a 10-gummy bear task as if it was just worth 1 or 2 gummy bears!
3. On telling people about Agile: Maybe the terms are intimidating.
I was thinking about it. Maybe people we talk with about Agile find it difficult to grasp sometimes because of the terms used.  As with almost anything, we have to learn the vocabulary of the technology and techniques that we use.  But communicating it to potential clients and potential developers on the team might not be as easy all the time.  As what I've learned in Domain Driven Design (Quickly), there is a need for a 'common language' so it might be a barrier for Agile to be mainstream here. Or something like that.
4.  There's nothing like a group of people who value learning.
And when you get together, you get to share different views on matters.  Like JM. During the morning, there was a time that he was talking about the merits of Agile.  Then at a later time, he was also pointing out why Waterfall is still prevalent. At the same time, we have different perspectives of people who have also read up and/or experienced being in an Agile dev team.

I am looking forward to this weekend's training :) It's the 2nd part.