I've just had some training on SCRUM and Agile methodologies. Of course I've read about Agile and XP for several years now, but now I'm being invited to really dive in and apply these concepts more formally to future projects. If you want to get a quick feel for philosophy, read the Agile Manifesto. About half of what I heard are things I think I'm already doing with project teams: be adaptive and flexible, perform iterative development, deliver working software early, work off a backlog list, be willing to do architecture and design and use cases and requirements gathering somewhat in parallel when necessary, don't be afraid to throw away code, and so forth. The big driving idea here seems to be that there is going to be a lot of change, more than anybody expects, in any project--so treat change as a big part of the job, not as a nuisance or something to be avoided.

Which leads me to change, and our attitude toward it. Most programmers seem to resent change, mostly perhaps becuase it means discarding hard work and starting over at times. I have long maintained that there are 4 stages to programmer maturity:

The 4 Stages of Programmer Maturity

1. Resist Change.
2. Tolerate Change.
3. Expect Change.
4. Embrace Change.

That's right, embrace change. It's a chance to do things better. Do you remember early in your career, when you finished your first or second really large project? If you're like me, you wished you could do it all over again, because now you could do an even better job. Somewhere over the years, programmers get jaded and prickly about change. Instead, when we get a massive change request we should think of it as an opportunity to do something even better. When we have to throw away code, we shouldn't think of it as a wasted effort: the code may be discarded but it still pays dividends as a stepping stone to refinement of the solution you are building.