The drive to improve the maturity of the IT processes has been around for a few decades. There have been some significant developments and evolutions in the maturity models that govern the software processes. Software Testing also has seen some very significant developments including enhancements to the existing models and introduction of new models. While I appreciate the methodologies that are used by each of these models, I see a larger commonality among all these models. They focus on what is not standard, what is not repetitive, what is not scalable and what ever else that is not right. Once we know what is not right, we try to prescribe solutions to fix the problems. So, organisations also look at these “inspectors” or assessors as people who probe for issues and deficiencies, and rate them at a certain level of maturity. Every assessment includes some information about the good practices, but the focus is generally on the “opportunities for improvement” by fixing the deficiencies. Little consideration is given to what has worked well in the groups or teams within the organisation and to see how that be replicated across the organisation. It is in this context that I consider Appreciative Inquiry as a means for organisational transformation. Shifting from what is not working to what works well or what has worked well is offcourse a major shift in the approach, and hence may require a lot of preparation and facilitation so that the efforts are driving the organisation towards its ‘desired’ end state. Appreciative Inquiry is not a new concept. In fact, it has been around since 80’s and has been used by a lot of practitioners facilitating change management. What attracted me is the focus on driving change through identifying the positive aspects (appreciation) of something successful and using that to design what will help in bringing in desired outcomes. Probably a very powerful and positive way of bringing in all those changes that we have been triggering through pointing gaps and prescribing fixes. I think I need to take a deeper look at this.
I test. Therefore I am.
