First Step--Establish A Code Repository (.NET or Java)

The biggest "anti-pattern" in software development I can think of is to have production code floating around on developer's machines unversioned, unmanaged, and (most importantly) unarchived. I feel that it is better to have code that doesn't compile than it is to have code that isn't there. Each line of code represents human labor and expense for an organization. Many of us have laptops that we carry around when we develop, and inevitably we will lose them and have them stolen. I'd rather have developers do a daily check-in to a sandbox branch and merge later (something Humble and Farley frown on) than to risk having code destroyed or lost.
I am not a code repository expert, but I've used Visual Source Safe (VSS), CVS, SVN (Subversion), and to a small extent Git. I will shortly be moving to Microsoft Team Foundation Server. You can argue with people about their particular favorite platform until you are blue in the face, but in the end, if you don't have a code repository, get one and use it as soon as possible. This will elicit a big "Duh" from thousands of you out there, but you would be surprised how many shops still use a mapped drive or back up the code onto CD or DVD periodically.
I am most familiar with SVN, and while it isn't perfect, it is free and fairly well documented. I am very much intrigued by what I see from Git (it is a distributed control system that is gaining in popularity), and I plan to present something on it once I have more time to research it and make some recommendations. However, if you are a small to mid-size shop, chances are you have people who have used subversion elsewhere. The biggest complaint many people had about SVN was how hard it was to install for those of us (and I count myself one) who are not network and hardware gurus. That has changed with CollabNet Subversion Edge. CollabNet, the creators of Subversion, have put an easy to use web front-end on SVN administration and wrapped it up into an easy to install Windows installer. For the average development team this should be more than enough as it is both free, and limited only by the drive space you give to your repository. It integrates with LDAP, and keeps itself up to date.
If you are still using Visual Source Safe, while it is better than nothing, it has been discontinued by Microsoft and has problems. Additionally, I feel that it discourages collaborative coding by allowing people to check-out files and projects for long periods of time without checking them back in. Initially this saves on merging issues, but in the long run, I feel it slows a team down. There are additional technical issues you can read about on Alan De Smet's webpage. The basic feel I get from reading around is that VSS is itself an anti-pattern.
Here are some principles I would follow with whatever you choose to pick as your source code repository and versioning tool.

1. It is better to have the code worked on and checked in in small chunks into the trunk. This is easier if the team is co-located. If not, you may have to create sandbox-branches for developers and communicate what needs to be merged differently than simply turning to your programming team and telling them.
2. Everything needed to build your project should exist with the project (or be available from a tool like Maven). A project needs to be built with a single command and an argument for debug, production, etc. releases.
3. You must require people to enter some form of comments into the repository tool (especially after the inital check in). Preferably this will include some kind of link back to a change request or bug tracking system.
4. Create two branches at the time of release for the project. One should be a "tag" (a snapshot that is NEVER edited afterwords) and a true branch where you will work on correcting bugs and will eventually merge back up to the trunk. This should allow you to fix issues you find with a release while still moving forward on the next release. However, merge often and kill off branches without mercy when you are done with them.
5.  Put configuration information, release notes, and some basic documentation with the code, but think about investing in a CMS (Content Management System) like Alfresco or SharePoint for your end-user and technical-user documentation. Unlike Humble and Farley, I don't think raw Subversion is the most appropriate place to do document collaboration and content management. It works, but there is so much more you can do with a real CMS.
6. Keeping with the Agile concepts of maintaining transparency, shared ownership, and allowing for honest inspection, I would provide at least a read-only access to your code for other developers, managers, and even well-informed, non-technical members of the team. Extra eyes on code can only help. Hide nothing as "sunshine is the best disinfectant."
7. Avoid checking in anything but the code, the required resources, and the build script. Let the developer import the resources and create their own Projects, Solutions, Workspaces, etc. Everything should be based around your build script needing one and only one command to build the application. This will set you up well for the next steps in automating your code production line.

Clients

In keeping with trying to keep this general, I'm not going to recommend a specific toolset. However, I've used Tortise SVN (from Windows explorer), the various Eclipse plug ins, and AnkhSVN from Visual Studio for SVN. I've used the command line as well and plain old cvs commands. AnkhSVN works very well for anyone doing .NET development (and it is free). Chances are you may have to use a variety of clients depending on your situation. I'm in a heterogeneous environment so I use Eclipse, TortisSVN, and AnkhSVN for a variety of tasks.

Thoughts on Agility--Foundations

The semi-legendary Chang San-Feng, the founder of Tai-Chi noted that agility and stability requires a sense of balance. In order to move up, one must be mindful of his roots and his foundation or he will topple over and fall. It is very common for novice players of Tai-Chi to get wrapped up in the movements of their hands, the foot that is extending, the posture that they are striving for, and the myriad of other things that they put their attention to at the expense of their supporting foundation, their connection with the earth.
Likewise, recently, I've been contemplating this as I've been coaching teams in moving to Agile development (mainly in Scrum). The form, the activity, the artifacts become more a point of focus than the foundation. I've gotten caught up in it as well. At its roots, Agile is about being humane to one another, being flexible and adaptable to changing situations, and being radically honest about ourselves and our work, making what we do as transparent as possible. Everything else should just be a support framework to allow this kind of development. My "Agile Development" cannot and should not look exactly like your "Agile Development." Agile Development is an emergent phenomenon not a proscribed way of doing things.
That being said, much like learning Tai-Chi, having a form that you use as a framework to teach the principles helps. Scrum can act as such a framework, and a community can make it as heavy-handed and cumbersome or as light-weight as they see fit. I feel, however, that this outward expression of Agility is less important than putting into practice the philosophy espoused by the Agile Manifesto and some basic XP and TDD (Test Driven Development) coding practices supported by good Continuous Integration practices. If these two elements are missing, the whole Agile initiative is put at risk.
At its heart, any Agile methodology has to espouse the goal of creating quick, verifiable feedback loops between customers and developers. Listening, discussion, and change can only happen when everything is set up for rapid iterations that deliver "finished" and "verified" features that meet the customer's needs and expectations. A conversation cannot take place easily in an environment where there are lags that interrupt the tempo of discussion.
I'm currently reading Continuous Delivery by Jez Humble and David Farley. So far it is a really well informed, practical guide to the whys and hows of creating a "deployment pipeline." I especially like the idea that we need to focus on "done" being "deployed" as opposed to "in testing by SQA" or "being looked at by the deployment team." Far too often, development teams wash their hands of the responsibility for getting their code into production. Often, this is reenforced by the organization itself. Development departments often put their less skilled developers into testing teams, configuration management teams, and deployment teams when in reality these are the places that most need skilled, experienced developers who know the pain points associated with getting code tested and into production. In my experience this encourages lots of manual configuration and opens the door for human error as complicated steps must be followed exactly (often accompanied by kluges that are server specific).
In the next few posts, I'm going to walk through a sample pipeline for .NET that uses open source solutions for each step of the way. I'm specifically using technology that has analogous (or identical) implementations in JAVA as my current work involves a heterogeneous environment that requires that the same pipeline handle both platforms. I'm moving into a Team Foundation Server environment soon, and will discuss that platform later.

The Importance of the Daily Stand-up Ritual

Ritual gets a bad rap in today's world. To many people ritual  represents a fanatic kind of throwback to monks in cells self-flagellating while reciting the Lord's Prayer. To others, ritual means spiritless activity done without the  knowledge of what the original activity was meant to do. Google "Cargo Cult Agile," and you will find many complaints that Agile methodologies often devolve into "cargo cult" style motions without meaning. However, if one reads more about myths and rituals from the anthropological or sociological realms, even seemingly empty rituals can serve to add social and cultural cohesion to a group of people. Adhering to an "orthodoxy" can help a group of people maintain good habits as much as it can supposedly stifle a nebulous concept such as "individualism."
No place is this better seen than in the daily stand-up that many Agile teams practice as part of their "Agile Orthodoxy." Jason Yip's article It's not just standing up is a great guide for outlining how the daily stand up should be run and why it should be run in a particular way, but the reasons for the daily stand-up go much deeper even than commitments to the team and to a product. A daily stand-up is the ritual that helps forms and supports a community dedicated to a single goal. Aristotle viewed that mankind was engaged in three types of endeavors. First, is theoria, which is the endeavor towards enlightenment and theoretical knowledge. The principals of Agile outlined in the Agile Manifesto are the theoria of what we do. Second, was the idea of poiesis, the making of things (and also the root of our word poetry). We as human beings are hard-wired to create things and be creative. Finally, Aristotle saw that there was an endeavor he named praxis or the putting to practical use our theoretical and creative endeavors. I view the daily stand-up as our praxis or our daily practical application of our theory and creative selves towards forming a team. If practiced early in the day, in a co-located place, it is a very practical way to make sure everyone is working around the same time and the same place as a community or a team. It helps team members make commitments to each other and be a part of a group. None of us usually wants to let down our friends and co-workers. Finally, the daily stand up helps us to share our problems with our team members and receive sympathy, help, understanding, and a host of other benefits that communities bestow upon their members.
When doing the daily stand-up, I think the questions that need to be asked are as follows:

• What did you accomplish for the team yesterday?
• What will you accomplish for the team today?
• How can the team help you with problems you are having?

The emphasis needs to be on the team and not just the individuals on the team. By focusing on the team, we are able to ask people what they did to help the common goals as well as how the team can help the individuals. Social animals that we are, we need to know that we are part of something bigger and that we have our interests being looked after by the group at large.