I first heard (came to know) about this word from James Bach and this immediately caught my attention. I started seeing it everywhere. The phrase "goal displacement" is generally referred to a situation where method of achieving something dictates the out come and goal. The process by which the means used to achieve a goal becomes more important than the goal itself.
Here is an example that I think illustrates what I mean by “Goal Displacement”.
A model of Test Automation
Manager: I am quite impressed with overall progress this automation project. But I would like see some metrics and measurements to quantitatively monitor future projects in this area – like number of scripts produced per day, individual automation engineer’s productivity etc
Me: Ummm … right now, our model of automation development does not itself to such measurements. We don’t treat overall work in terms of scripts and measure engineer’s productivity. I am afraid; I don’t have an easy answer to your question
Manager: I understand your concerns. But I need those metrics.
Me: Here is a deal, how about modifying the whole process of automation such that it is easier to measure and exactly built according to metrics that we would like to measure (regardless of what outcome we would like produce)?
Manager: I did not understand that … Can you not just introduce them to existing model without affecting anything else - especially the output?
Me: To accommodate the kinds of things that you are asking, I will have to modify the way we develop things – which I am afraid will affect the quality of our deliverables. I don’t see any way to make those measurements in current model.
Manager: Metrics and measurements are not suppose to change the process instead I heard that metrics help to control and improve the process.
Me: In this case they do. Do you want me go ahead and change? I see a serious, negative side effect of changing the process/model to suite metrics.
Manager: Ummmm … Let us talk about it some other day (walked away)
What is happening here? Manager wanted to see some metrics to see how the automation team is performing. I simply said "You can have those metrics but at the cost of changing a process that is apparently working fine and producing the results that make you happy". So here, the introduction of metrics (or a measurement process) causes a shift in the goal of producing good automation code to goal of having a process that measurable in some way. It is like saying if current process (way of doing things) does not cater to a new related expectation, possibly a conflicting one with original goal (a displaced goal) - then forget about goal - do whatever change required to meet new goal or expectation.
Stay tuned for two more examples of goal displacement ...
Shrini
1 comment:
Hi Shrini,
This is indeed a big problem in our software industry. I have experienced it personally. In our team suddenly they said that we will have KPI's for measuring test engineers productivity. Prior to having all this non measurable stuff things were working very fine, quality of Bugs found was great and engineers were devoting time to find bugs and test using different techniques. However lets see what side effects this measurement concept gave to my team:
One of the KPI's given to our team was that on an average their should be 1 bug per day logged by a person and eventually it was suposed to rise to 1.74 to achieve the figure on a Business Unit level.
The Outcome:
Every one was counting how many bugs he needs to log in the system and by which date. Any stupid bug or just anything was getting logged into the system like a page is not opening, lets log a bug, server is down lets log a bug.
The main goal changed from quality oriented bugs to number of bugs logged so that in the ALL HANDS meet they will get recognition.
In my perspective the type of bug logged and how crucial the bug found was, what impact that bug had on the application, what would it have costed to fix it at a later stage in case the bug was founded later, what was the scenarion in which bug was found were all important factors in deciding the performance of test enginner and not the goal of achieving 1 Bug per day.
Their were long discussions about how many bugs have a person logged and how many more he needs to log in the system in the Cafetaria's.
On top of it their was a PDF attachment sent at end of every month containing a list of all people with number of logs they have logged and declaring someone to be the winner.
What impact it had on good test engineers?
If i consider my case then i logged very good bugs which were all never seen by anyone though the application was being tested from 2 years, all were accepted by development team as valid bugs, most of them very quite critical in terms of usability of the application, some of them were pertaining to context getting lost in navigating to next pages and coming back to previous ones.
But since the no of Bugs which i raised was very less in compared to their goal of 1 bug per day and i was never satisfied with this idea of implementing this for all people in the whole team where most of them were working on independent modules which are definitely different from others.
The Bugs found will also be different and will be of different severity and found for different applications.
I can say this is a perfect example of the Title for the post.
"When method dictates outcome and Goal- See Goal displacement in action".
Do you agree?
Post a Comment