My first project for ThoughtWorks involved changing the project's process to use Extreme Programming. It was a long, difficult effort, but ultimately we succeeded. Afterward, I admit to being somewhat smug. I knew XP, this project proved it. Part of this smugness came from the fact that some of my teammates had come from earlier ThoughtWorks projects that had purported to use XP, but were (in my then mind) not practicing it correctly. Several of the practices introduced early into our project, were not much like XP as commonly discussed in the community (or practiced by me elsewhere), and did contribute to some early adoption issues we encountered. By shifting toward more typical XP descriptions of those practices, we got traction, and ultimately success.

Now I knew what XP was. So, on my next project, I introduced those same practices -- aiming for implementations similar to those that proved so successful on the previous project -- only to find that they were now completely wrong for the team and culture. I concluded that the problem was context-specific crud inadvertently left-over from the early version of those practices on the previous project. Removing this, (i.e. shifting even more toward what I now considered typical XP implementations of those practices) brought us better results, and ultimately success.

Now I knew what XP was. So, on my next project...

You see where this is going. It was three projects (four if you count the ideas that seeded the first), before I began to realize that you can't separate context from implementation of practices -- XP or otherwise. Each time I found certain principles carried over, but I also found that while there were simularities in implementation (to a greater or lesser degree) there was little (nothing really) that when cookie-cutter applied in the new situation netted the same results as on the previous project.

And this was for the marginally successful practices. It took me even longer realize that this mind-set was appropriate for the most successful practices as well. Just because something was a smashing success -- the break-out idea that got the team's velocity up, and led to smooth sailing the rest of the way -- didn't mean it was immune to this reexamination on the next project.

There's been several more projects since then, but I still struggle with this today. While rationally I feel that I would be willing to abandon or modify any practice (even the divine practice of TDD) if it wasn't helping us ship software, there are certain prejudices I bring into each new project, and an inevitable 'aha' moment when I realize how that prejudice is blinding me to what will help most. Mainly that moment just happens sooner (IOW, I am quicker to look to myself for the problem!).

I believe that this pattern applies to practices, values, and even principles: what works for us in the past, what we feel makes us successful, or even who we are is based somewhat on the accident of experience (or chance), and may prove disastrous when blindly followed in an inappropriate circumstance. Prejudicial thinking is difficult to notice in oneself. How much harder it is to detect when reinforced by culture, early experience, and prior positive outcomes.

These days, I believe the key difference between practice, value and principle (something much debated at one time in the XP community and elsewhere) is simply how likely we are to adjust them if things are going wrong for us (i.e. practices change a lot, principles rarely). But none should be immune from our consideration when our actions result in negative outcomes.

My advice (BTW my meta-advice is don't look for advice on starting projects, plan to work it out for yourself, you will anyway): Start each project with a blank process sheet. View the ideal process as a seamless flow of software from implementors to users. Find what's gumming up that flow, apply the contents of your experience toolbox (i.e. the processes, practices, values and principles you've collected to that point) to the rough spots until things run smooth. Never stop looking for new things to add to your toolbox. Always know what your goal is. Never stop learning. Never believe you've got it all figured out.

Most importantly: never be so stubborn about what you think you've learned about success, that you aren't willing to change.