The term "Agile Transition" strikes me these days as having a bit of built-in misnomer. It implies that agility is binary -- that a team is either "agile enough," or "not agile enough." So, I ask, what is "agile enough"? Who determines this threshold? Certainly not me. Agility is like quality. There is always more of it to acquire.

This is part of the reason I am understanding of teams experimenting with agility. They're on the agile path, and so am I. As I've said elsewhere, our similarities matter more than our differences. I honor those similarities.

Specific practice recipes aside, the main thing is simply to stay on the path, to keep pursuing more agility, to neither be judgmental nor complacent. This attitude is tremendously important to successful "transition." We could all improve, but where we are is OK for now. If we cannot be OK with where we are now, we make ourselves crazy.

In general, I prefer to work with all of the "Second Edition" Extreme Programming (XP) practices, whenever the circumstances permit. That's where I am on my agile path, using those practices, and a few others, striving always to improve my use of them. There is certainly plenty of agility left for me to master.

Given that a team does want to start adopting agility, what approaches work, and which don't? Does it matter where you start, and how you proceed?

Absolutely it matters how you start, but that's the end of the absolutes. I have my preferences, and there are patterns emerging in the industry, but it increasingly seems inherent to agility that different approaches suit different contexts. This is not just some excuse for laziness, or some opportunistic pandering on the part of consultants with their own specialties.

It is genuinely the case that the right approach for one team will not work for another. In general, though, here are my preferences.

Without strong commitment on management's part to get serious about agility, I don't think anyone has seen strong positive results (though the individuals involved may be growing more agile). While I believe that non-agile approaches are typically riskier than agile transition, and healthy agile teams have much lower inherent risk than non-agile teams, agile transition itself does have its own risks, and consumes resources. It takes time and money to learn new principles and practices. Some manager somewhere must pony up to those risks, championing the transition to shareholders higher up.

I used to council starting every time with iterating and with Test-Driven Development. These days I council starting with building the strongest local agile community you can: start with the Whole Team practice. Healthy, whole teams have steadily increasing levels of ambient trust, respect, and cohesion -- a sense of collective identity. People on such teams enjoy working with each other, even if the work itself is still sometimes arduous. This is the foundation upon which the remaining practices must rest.

So start with specific actions like putting everyone in the same big workspace, tearing down the cubicle walls. Start trying to integrate the code to a problem-free code repository at regular small intervals. In this matrix-management age, try to ensure that the team works on a single project at a time (where possible), and stays together for months at a time. In the same way it doesn't make sense to pick up all the cab drivers in Chicago and swap them with drivers from Miami (and expect to get to the airport on time for awhile), it doesn't make sense to shuffle programmers back and forth unnecessarily between complex problem domains, codebases, and teams. Too much such context switching generally leads to churn and chaos.

Get the customer sitting with the team if possible, looking over people's shoulders and asking and answering questions. Barring that, create rigorous, scheduled rituals of daily phone-calls or Skype video calls between customer and programmers. Publish local team results on big visible charts that everyone can see on the walls, and/or track projects using tools like wikis or VersionOne. Get people doing stand-up meetings every day, even if they are not iterating yet, and yesterday is much like today. Get them to do weekly retrospectives, even if this week is still much like last week.

At that point, once a strong Whole Team has been established, I think there are several ways you can go, depending on your tolerance for risk, chaos, and temporarily reduced productivity. I would start with the local points of worst pain, and apply the practices that address them specifically. If the wrong features are routinely being delivered, for example, then I might council starting to deliver work iteratively in the form of Running, Tested Features. This might pull along with it the agile estimating and planning techniques to be found in the excellent books of Mike Cohn's: User Stories Applied and Agile Estimation and Planning. If the principle issues are codebase rot, intolerable defect rates, and long, intractable test and debugging phases, then it might make sense to adopt Test-Driven Development and Continuous Refactoring early on, even though it takes the average veteran programmer years to master these practices.

This, too, is contextual. The common wisdom for years was that it made sense to transition one team at a time, with pilot projects. After proving the practices, you would then perfect the local agile recipe, the reasoning went, and then systematically roll it out to the rest of an organization's teams. But at least one quite large software organization -- with more than 500 programmers -- recently presented results at an agile conference showing that it made sense to them to transition the entire organization at once! They temporarily exhausted a large team of agile coaches in the process, apparently, but had excellent results.

Be agile about your agile transition. Add a practice, attempting to roll it out to a team in good faith, and measure the results. Work to get buy in, to empower emergent, steady learning. Work to assuage fears, to celebrate positive results.

Be patient if things get sticky. When all else fails, return to ways to create even more community. Do anything else you can to bring people closer. Celebrate every small success with food. Never underestimate the power of pizza and Dance Dance Revolution. Study how people can listen to each other better. Remember, the goal is more trust and respect, more honor and compassion. With enough of it, teams will walk through fire for you.

-- Patrick Wilson-Welsh, Adaption Software     revised 8-7-06

[More of Adaption's Articles.]