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.
Followers
Tuesday, September 29, 2009
Thursday, September 17, 2009
Autonomy, Mastery, Purpose... Motivation
Money only motivates for a limited time. Have you ever held a job, where the only purpose you held it was to earn money? How motivated were you to excel in what you do? How much time did you devote to the job outside of the organization? How did this make you feel?
I watched an interesting video on TED from Daniel Pink about the the surprising science of motivation. Now, because he admits to being a lawyer, I don't take everything he says to be fact ;), but the underlying theme resonates with how I feel about motivation. There is more to it than money. Even people who are motivated to gain money are usually doing so for some other thing, not the money itself.
Up here in Aroostook County, Maine, where I live, teenagers sometimes participate in the annual Potato Harvest. This is a long held tradition, but a difficult job. It offers long days of physical labor, taking rocks and other debris out of the conveyor belt that is loading the dug up potatoes onto the truck that runs along side the harvester. It can be at or below freezing in the morning and hot in the afternoon. This is what fall is like up here. You go home covered in dirt/mud. You are exausted, and the morning comes early the next day. The motivation for completing a harvest job may appear to be the money, but if you look at it a little more closely, it is the goal of the money that is the motivation.
The speaker lists of three things that could be the reasons we are motivated: autonomy, mastery, and purpose. These motivators ring true with me, but I would add a couple more: passion and self-gratification being two of them. By our very nature, we like to feel good about what we are doing, it has to give us some sort of gratification in order for us to excel at it. Even those who live to serve others continue to do so for some sort of gratification.
It is easy to be motivated when you are on a project that is exciting or new. Sometimes the tasks or projects that we have to do are alot less meaningful. During these times, when doing the mundane or less than exciting tasks associated with my testing or my life, I find that I have to purposely motivate myself. I do this by looking at the big picture instead of at the task itself.
Anyone who has had a child or a puppy can understand the big picture mentality. My German Shepherd, Henry, is still a puppy. He is only 8-months old at this time. There were times during the last four months when only looking at the big picture motivated me to continue training him up to be a part of my family :)
I question just about everything, whether aloud or in my head. When I come to a point where I feel less than motivated, I ask myself why. Then I look at the big picture. If the lack of motivation cannot even be rectified in the big picture, I look for an alternative. Because of my passions and my admitted need for self-gratification in what I do, I agree with the speaker in this video... what drives my motivation is autonomy, mastery, and purpose.
I watched an interesting video on TED from Daniel Pink about the the surprising science of motivation. Now, because he admits to being a lawyer, I don't take everything he says to be fact ;), but the underlying theme resonates with how I feel about motivation. There is more to it than money. Even people who are motivated to gain money are usually doing so for some other thing, not the money itself.
Up here in Aroostook County, Maine, where I live, teenagers sometimes participate in the annual Potato Harvest. This is a long held tradition, but a difficult job. It offers long days of physical labor, taking rocks and other debris out of the conveyor belt that is loading the dug up potatoes onto the truck that runs along side the harvester. It can be at or below freezing in the morning and hot in the afternoon. This is what fall is like up here. You go home covered in dirt/mud. You are exausted, and the morning comes early the next day. The motivation for completing a harvest job may appear to be the money, but if you look at it a little more closely, it is the goal of the money that is the motivation.
The speaker lists of three things that could be the reasons we are motivated: autonomy, mastery, and purpose. These motivators ring true with me, but I would add a couple more: passion and self-gratification being two of them. By our very nature, we like to feel good about what we are doing, it has to give us some sort of gratification in order for us to excel at it. Even those who live to serve others continue to do so for some sort of gratification.
It is easy to be motivated when you are on a project that is exciting or new. Sometimes the tasks or projects that we have to do are alot less meaningful. During these times, when doing the mundane or less than exciting tasks associated with my testing or my life, I find that I have to purposely motivate myself. I do this by looking at the big picture instead of at the task itself.
Anyone who has had a child or a puppy can understand the big picture mentality. My German Shepherd, Henry, is still a puppy. He is only 8-months old at this time. There were times during the last four months when only looking at the big picture motivated me to continue training him up to be a part of my family :)
I question just about everything, whether aloud or in my head. When I come to a point where I feel less than motivated, I ask myself why. Then I look at the big picture. If the lack of motivation cannot even be rectified in the big picture, I look for an alternative. Because of my passions and my admitted need for self-gratification in what I do, I agree with the speaker in this video... what drives my motivation is autonomy, mastery, and purpose.
Saturday, September 5, 2009
A Lesson Worth Learning
One of the projects that I am currently involved in is being developed using agile/scrum methodologies. The product/application/system has no previous/historical test documentation. This is a huge opportunity for learning. While I have done quite a bit of reading on situations similar to this, nothing really compares to being involved in one.
How easy it is to forget things, usually by way of assumption, has been one of the first lessons that our team has been learning. A generic example of this:
Feature A is being implemented in this sprint based on a User Story.
The whole team worked together to break it down into tasks/SBI's during the Planning meeting.
Unit tests were created during the development of the feature.
The feature was implemented according to the User Story.
The tasks/SBI's were completed.
The Unit Tests passed.
But...
The User Story assumed that certain limitations would be in place by default. There were missing requirements that were not considered during the implementation of the feature. According to the Conditions of Acceptance on the User Story, the feature is done, but outside of the task board, it is not.
We have faced this challenge a few times. Fortunately, our team communicates efficiently/effectively. When these challenges have come up during a sprint, they have been discussed and dealt with according to the potential impact on the project. It could be that a new PBI has to be composed, a bug is written (either to be fixed within the sprint or deferred), and sometimes technical debt is incurred.
This challenge of remembering not to assume has had a positive impact on each of us as individuals and as a team. Individually, I remembered the
Rapid Software Testing course that Michael Bolton delivered to our team a couple years ago. Specifically, I remember the lessons on inattentional
blindness. I have decided to go back through the materials from the RST course to refresh myself and to pass on relevant information to the others on my team. You don't have to be a software tester to benefit from this course.
As a team, the impact of this challenge has helped us to communicate stronger, rely upon each other, and it has kept egos at bay. We realize that not any one of us can come close to remembering what all of us together can. And while on the surface, this challenge can appear to be of a negative nature, it has produced positive change - and that makes the whole lesson worth learning.
How easy it is to forget things, usually by way of assumption, has been one of the first lessons that our team has been learning. A generic example of this:
Feature A is being implemented in this sprint based on a User Story.
The whole team worked together to break it down into tasks/SBI's during the Planning meeting.
Unit tests were created during the development of the feature.
The feature was implemented according to the User Story.
The tasks/SBI's were completed.
The Unit Tests passed.
But...
The User Story assumed that certain limitations would be in place by default. There were missing requirements that were not considered during the implementation of the feature. According to the Conditions of Acceptance on the User Story, the feature is done, but outside of the task board, it is not.
We have faced this challenge a few times. Fortunately, our team communicates efficiently/effectively. When these challenges have come up during a sprint, they have been discussed and dealt with according to the potential impact on the project. It could be that a new PBI has to be composed, a bug is written (either to be fixed within the sprint or deferred), and sometimes technical debt is incurred.
This challenge of remembering not to assume has had a positive impact on each of us as individuals and as a team. Individually, I remembered the
Rapid Software Testing course that Michael Bolton delivered to our team a couple years ago. Specifically, I remember the lessons on inattentional
blindness. I have decided to go back through the materials from the RST course to refresh myself and to pass on relevant information to the others on my team. You don't have to be a software tester to benefit from this course.
As a team, the impact of this challenge has helped us to communicate stronger, rely upon each other, and it has kept egos at bay. We realize that not any one of us can come close to remembering what all of us together can. And while on the surface, this challenge can appear to be of a negative nature, it has produced positive change - and that makes the whole lesson worth learning.
Subscribe to:
Posts (Atom)