Over on the altnetconf list the question arose as to where you start when implementing agile within an organization. The first thing to bear in mind is that you probably want to avoid implementing all the practices, at the same time. This is likely to cause you to fail, because your attention will be split across too many activities. (Of course this is true for an existing organization where you do not have experienced agile developers. If you are in the fortunate position of putting together a new team with experience agile developers, you are going to bring your practices on board much more quickly, but you also don't need this advice because you will understand how to get there from experience.)
The advice from Beck in XP 2nd Ed. on implementing agile is to start with one of the XP practices: "It's easy to start by changing one thing at a time. I think it's hard to jump in and do all the practices, embrace all the values, and apply all the principles in novel circumstances by reading this book and deciding to do it. The technical skills in XP and the attitudes behind them take a while to learn. XP works best when it is done all together, but you need a starting place."
So where do you start? When trying to bring agile into an organization you want to think about resolving key pain points. Resolving visible pain points using agile practices will demonstrate the value of agile practices and encourage buy-in for further change. What that pain point is will vary by organization.
Here is how we put agile in place at my current organization. One thing to point out up front though is that in all of these cases, whilst I can identify the starting point, we are continuously improving, so while we may have initiated use of a practice that does not mean we were as good at it as we are today, not does it mean that even today we are perfect on any of those practices. Agile is a process of continual reflection and improvement.
We started with build, because there was considerable pain around the existing build and configuration management process which was based off building with devenv, using sourcesafe for source control. Build required a full time developer to manage, there were huge versioning and dependency issues and branching off the main code line for a release was a fraught process. A new developer often found it took them two days to set up their box to build locally. We began by pushing NAnt scripts as the preferred build mechanism, re-structuring applications to a standard format to allow us to develop internal build libraries and integrating cruise control so that projects built with any check in. This was not an overnight process and we had to go through a number of iterations, but once your build process is repeatable and automated a lot of the pain goes away. We slowly further improved the build process as developers mastered previous technologies for example swapping SourceSafe for Perforce (Subversion is a good alternative too) to do SCM.
Next we introduced TDD as soon as we had a new project. hey had a lot of bugs going into QA, and even into live, and some quite byzantine architectures, so we knew we could make things visibly better. It is easier to introduce TDD on a greenfield project because it is easier to get a system under test from scratch. Legacy code projects require the most knowledge to put under test and starting your journey into TDD with them often has low rewards for high effort. That tends to lead to disappointment and frustration among developers that TDD is not helping them, and you will find it hard to encourage them to to continue to practice test-first approaches. Conversely, TDD on a new project will show people the benefits much more clearly and once they are sold on the principle you can look at those legacy projects. I was asked on altnetconf if I would start with TDD if I had a greenfield project to go when introducing agile, and yes, my experience so far suggests that CI and TDD would be my first port of call in such an environment.
My experience is that it takes a developer around 6 months to become truly test infected. They will be slower while they learn the techniques, perhaps 25-50% on experience. During that period you will have to pressurize them to write tests first, especially when schedule pressures would otherwise cause them to slip back into hacking their code out. Be prepared for some of the team to feel about you the same way that a recruit feels about his drill sergeant, because you keep banging on about tests. My team rib me now, but I am sure there are periods where they didn't like me. Once you are through the pain, they will swear off developing any other way, even the die hards who said their code did not need tests.
Then we moved to Scrum and introduced the idea of iterations, stand ups etc. (we had used stand ups earlier without bringing in the rest of Scrum). This one causes conflict with any existing project managers who come from a Prince 2 background, so needs buy in from the top to make them conform. But, by far, the biggest issue here seems to be end user buy-in. Some of our projects still drift into waterscrum with a long deployment phase and UAT period because we cannot get the feedback we want during an iteration. Again its about the users learning the value of their involvement over time.
For deployment we reached a confidence point with our NAnt scripts that we were able to deploy to development and later to test and production environments automatically. As an aside we use XMLPoke to push in values into configuration files that change with each environment, so we just maintain a separate 'include' file for each environment we are targeting, that gets pulled in by the build. We also reached the point of authoring our own NAnt tasks now, so that we can solve local issues, such as uploading document templates for our document generation process, as part of the build.
At this point we tend to use Crystal Clear as the source of our development practices like Exploratory 360, Blitz Planning etc over XP to extend. Personal preference perhaps, although my previous shop was nominally XP and actually didn't look a lot different by the time we had decided what practices were working for us and what weren't. Looking over at the white board our team is currently practicing: TDD, CI, Side-by-side programming, Daily Stand-up, Planning Poker, Burn Down Chart, Coding Standards, Reflection Workshop/ Sprint Review, Exploratory 360, Blitz Planning/Sprint Planning, and Two-week iterations. Of course those practices could change if we don't think they are working for us.
I think the key point is though, you need to look for where agile can surface and solve the pain problems in your current organization. If you can make something better then people will start to view agile as a problem solver and warm to it.
My experience also suggests that agile is a journey. There is the idealized vision at the end, a perfect XP or Scrum team, but the reality is you are always short here and there, but the struggle toward that idealized model improves your software. We are not there yet. We have lots of shortfalls and keep working to make them better. next off our block is trying to improve our ability to get QA to test within the boundaries of our iteration. So don't be discouraged if you are not perfect, everyone else is just 'on the road' too. If you are on the journey don't get dispondent when it is a hard slog toward a finish line that always seems to be over the next hill. Glance back from time to time, and you will see how far you have come, and feel inspired to pick up your feet and keep marching forward again.