Over the past seven years, I've taken a few organizations "agile." In one case, the transition served as a morale booster -- it got people's minds off of an indeterminate future (dot com meltdown timeframe) and onto making the process work. In another case, it was a way to synthesize many different SDLCs across a company into one basic approach (taking pieces from each group, so as to make the resulting SDLC organically derived). I've worked with MIL-71 (a waterfall development methodology with documents on how to write documents), NASA development process standards, and agile approaches: XP, Scrum, FDD, and DSDM.
I'd have to say, I'm a true believer with respect to agile methods, but not a religious zealot about any particular one. In fact, with the youth of agile approaches as documented methodologies I have found they have holes. One of the most important (and, in my opinion underemphasized) tenets of "agile" is that you have to make the method fit your organization. There needs to be some agility in the application of the method itself. Thus, I believe every instantiation of any agile approach is distinct. I usually develop the methodology at an organization by starting from some named base methodology (say XP) and customizing it based on the culture and issues at hand. I usually don't call it by name, so that the host of objections to xyz methodology aren't introduced prejudicially.
Specifically to your questions:
- How agile methods make the working environment feel... In some cases I have encountered some resistance. In all cases, results trump skepticism, but it can take a bit of finesse to get people to participate before they are committed. The most tenuous time is that phase when the team is just starting out. The whole team is being led to interact in a way that is new to all of them; people feel vulnerable or even stupid. I've always seen teams develop confidence after working through the initial few days.
- Responses to increased face-to-face interaction... I've never seen a negative response to this. Some people do try and avoid it; they require a bit of coaxing by the team. (The team has to be groomed to take ownership of this situation, rather than having a single "process lord.") Over all, people become a team when they integrate their activities, and agile methods promote this. For people I would classify as loaners, with agile methods, I've seen them develop preferences for working with some people more than others -- perhaps people who better match their style. This is the kind of thing (I believe) a methodology has to be sensitive to and accommodate.
- Resources... I always start people with Kent Beck's XP Explained (bn) (amazon). If you can find a copy of the first edition, I actually like it better as an initiation than the second edition. Once you've read that, look at a different method than XP - perhaps DSDM (You can look at atern online for free at DSDM.org, but you have to register.) Then you'll get a feel for how "stories" in XP are just features or high-level requirements in other methodologies. You'll draw many similar parallels on your own. Once you've gone through those two sources, I'm sure you'll have identified many other sources and interest areas on your own. (One thing about DSDM - it's more popular in Europe than US.)
All that said, here are just a few common elements of agile methods that I would not ever leave out of any implementation:
- Short Iterations: The whole premise of agile methods comes from the notion that stakeholders need to see frequent, tangible results. They don't often know exactly what they want -- or, it can change once they touch a prototype and "feel" how it works. Incremental delivery builds credibility, causes prioritization and requirements management, helps ensure value to the customer (highest value features first), and is a source for financial savings (unneeded features don't get developed). Additionally, delivery dates are not fluid. Scope may change, but schedule has to remain fixed. I try and steer teams to durations of one or two weeks (so a bit of a departure from Scrum, which likes 30-day "sprints.")
- Daily Integration (daily build): This is really risk management. A large set of activities and procedures have to be set up (and automated) in order to have daily builds. Enforcing the daily build ensures that a team never strays too far from having a working product. Muscling the build is less apt to cause a missed deadline. (Missed deadlines are not part of the vocabulary of agile methods.) This also requires the team to work together in a way that is not just about writing code. An automated test suite should be part of the integration/build process as well.
- Group Ownership of Code: No one owns a particular module or class. Anyone can update or improve any part of the application.
- Group Ownership of Process: This is an emphasis I've developed through my own experience. Issues in process effectiveness are owned by and mitigated by the group. While the team is building applications, they are also building the process they use to build applications. It is important for the success of methodology that the participants take an active role in monitoring and maintaining the effectiveness of the methodology itself. One behavior that is not acceptable is for the team to point at the process as a reason for coming up short. (They'd have to point at themselves.) I evaluate this as a potential mechanism for any culture change initiative, not just agile.
- Unit Testing: Has to be part of application development, whether test-first or code-first, the test has to be there so that dependence on tribal knowledge is minimized and maintenance of a growing application remains scalable.
- Stakeholder Prioritization: Stakeholders (regard as your customers) determine what features get developed in what order.
- Obsessive Project Management: This includes the daily stand-up meeting; there should be some point in the day when everyone can be in the same place at the same time to air any issue. (Phone conference counts for offshore.) Some people think agile methods are loose. In fact, with short iterations, the project management in agile methods has to be tighter than other approaches. (Think quarters versus semesters in college.)
- Object Orientation: If the application is software, use OO and enforce encapsulation, polymorphism, inheritance. It raises quality (reduces defects) and makes the code more maintainable and easier to extend. (All worthwhile code gets maintained and extended.)
One other thing... I have found that it is way easier to implement agile methods on a new product or application. Bringing in an agile approach for the ongoing maintenance (or enhancement) of a legacy application is much more difficult (though still worthwhile, in my opinion). Why difficult? Because unit tests may not exist for the majority of existing code, the application build may not be automated, fiefdoms (code owners) have already been established, there might not be automated functional tests, etc. Many culture and behavior patterns have to change, and many infrastructure "tasks" have to be accomplished that are not perceived by stakeholders as high-value ways to spend time. You have to do some "selling."
Implementing agile methods is one of the most invigorating things I've ever done. The cultural issues are intriguing and fun to address. The results are inspiring.
I encourage you to explore... It's a great place to go. (Or perhaps I should better phrase, It's a great path to take.)
