Two testers on two different projects. Both working for the same organization. Both on an email thread describing processes/practices currently being used or intended on being implemented in the future - across the board - as best practices. For one of these future goals, tester A says it would be a good idea to implement it. Tester B says no thank you.
I was tester B. Later on, I was asked personally why I said no. I explained why, based on my project and my team. But I felt like I was missing something in my "arguement" and I felt like more explanation was necessary though I could not verbalize what that was. Days passed and I could not stop thinking about the missing peice. I could have argued about "best practices", but that did not seem to be the right route to take. I had to take some time to think this out, and time is a precious commodity when releases are pending and you have to balance those late days with your home life.
I kept talking to myself (I tend to do that alot :)) about the different projects in my organization. About how project A differs from B in some aspects, and project C is in a league of its own. The differences in the projects range from code language, release cycles, size of product/application, and how test leads manage what/how it is tested, etc. When you have multiple projects in test, it seems to be a valid point to attempt to take what works on one project and apply it to the others in an effort to have "best practices", so continuing to talk about the differences might only illicit that same feedback... so I continued to think about it.
I don't believe in adding processes or tasks to a testing project that do not benefit the success of the project. I need suggestions to be validated, even if it is in an abstract form initially, in order to see the value of doing something. I do not believe in wasting time because time is limited, testing takes time, and testing costs the organization money - it does not make money - so it should spend both wisely. Because I feel this way I think not only about whether or not a practice is best, but whether or not it is time/cost effective.
It was at this point that I remembered something. A compact fluorescent lightbulb went on just over my head... The Seven Basic Principles of the Context-Driven School. While I had read this before and read several debates over it, I had not realized the importance of what it was saying. This was my missing peice. Co-authored by Cem Kaner and James Bach, this is a very well thought out and written explanation of my sub-conscious reasons for not wanting to see processes/practices implemented across the board whether or not they benefit the individual projects (or taking that down to the root - whether or not they benefit my project).
Today I will share this explanation, along with my new found understanding of it, with those who asked me personally why I said "no". At the very least it will give us all something to think about and talk about.