I had the privilege to attend the Amplifying Your Effectiveness (AYE) conference this year. Finally! I've mentioned that conference in several of my presentations and talks over the years, so I was pleased to finally be able to make it out to Phoenix, AZ, this year for the event.
There isn't much I'm going to say about the conference at this time. Browse the conference web site to get an idea of the kinds of sessions and discussions that happen there. Reading about it doesn't do it justice.
Everyone I know who has attended an AYE conference in the past has told me how wonderful it was and how much I would enjoy it. They were right. Even though I was told to expect it, and I hoped it would live up to those expectations, I felt a kind of relief and happiness in knowing that I wasn't disappointed.
In my experience, I've noticed that testers tend to start out only interested in developing their technical skills (e.g. programming/scripting language, automation tools, databases, etc.) - if they show any interest at all in professional development related to their jobs. If you take your career and profession seriously, there will come a time when you realise that the technical skills aren't as important as communication and people skills.
Why does learning happen in that order? Does it make sense? Build People skills upon/after your Technical skills? Shouldn't we start with a good base in communication, understanding and relationship-building, and then work to develop technical skills and expertise afterwards?
Should we focus more effort on teaching teenagers in High School how to understand and communicate effectively with each other to prepare them for developing good working relationships in adulthood? Why is it that the High School/teenage experience tends to do the opposite?
I've seen my children play nicely with other kids, even strange/unknown children in the playground quite nicely. So when do adults forget how to be nice to each other? To play nicely or fairly with others? When do they forget how to show respect and trust, and act with integrity and honesty towards others?
At AYE, those values were apparent. I saw kindness, respect, trust and honesty in abundance. It was overwhelming at times. I wasn't expecting that. I felt a sense of instant community at the conference.
Learning happened. Sharing happened. Discussions and conferring happened. It was fun.
It was everything that I hoped how a group of adults would act. I wish that was a more common occurrence. I wonder what we could accomplish if more people acted that way.
The Price of Clarity
I went to a "Startup Drinks" event tonight and met some interesting entrepreneurs with lots of great ideas. One thing I discovered (about myself) is that I'm going to need to get on Twitter in the near future. ;-)
One person mentioned a tweet that he posted yesterday from the "Monday Morning Memo" about advertising. The tweet was about the topic "Why Most Ads Don't Work" (by Roy Williams, author of the book "The Wizard of Ads") and is summed up in the nine secret words: "The Risk of Insult is the Price of Clarity."
This was an interesting phrase. I instantly thought about the feedback that we, as testers, give about the products we test. You know what I'm talking about.. the Ugly Baby Syndrome. Sometimes we have to be the bearer of bad news. Hopefully, we can find a nice way to say it, but ultimately, I believe that the risk of insult is the price of clarity.
Thinking about my motto "ubi dubium, ibi opportunitas" (where there is doubt, there is opportunity), we often exploit the vague, unclear areas of products and applications.. because there will usually be lots of bugs there. The bugs we report are about more than just little typos and minor UI issues, though. If we do our jobs well, bug reports can be the catalyst to help bring clarity to features/requirements/implementations and consensus among the stakeholders about the app/system under test.
When I test, I report every bug. It's all information. I can't judge when something will be worthwhile (to report) and when something won't. You won't recognise that your baby is ugly because it has thousands of little things wrong with it if you don't report the thousands of little things. It's not often that you'll test a system where you find a "nose" in the completely wrong place, or an "ear" where an "eye" should be (to continue the 'baby' analogy). Those moments are easy - you *have* to risk the insult or risk completely failing to meet the customers' (and other stakeholders') needs.
If you test, and report bugs, in a way so as to "not offend" (i.e. by watering down the message, not testing certain features too hard, or choosing not to report certain bugs) are you really providing a helpful service?
What are you willing to risk to ensure clarity on your projects? What do you think?
One person mentioned a tweet that he posted yesterday from the "Monday Morning Memo" about advertising. The tweet was about the topic "Why Most Ads Don't Work" (by Roy Williams, author of the book "The Wizard of Ads") and is summed up in the nine secret words: "The Risk of Insult is the Price of Clarity."
This was an interesting phrase. I instantly thought about the feedback that we, as testers, give about the products we test. You know what I'm talking about.. the Ugly Baby Syndrome. Sometimes we have to be the bearer of bad news. Hopefully, we can find a nice way to say it, but ultimately, I believe that the risk of insult is the price of clarity.
Thinking about my motto "ubi dubium, ibi opportunitas" (where there is doubt, there is opportunity), we often exploit the vague, unclear areas of products and applications.. because there will usually be lots of bugs there. The bugs we report are about more than just little typos and minor UI issues, though. If we do our jobs well, bug reports can be the catalyst to help bring clarity to features/requirements/implementations and consensus among the stakeholders about the app/system under test.
When I test, I report every bug. It's all information. I can't judge when something will be worthwhile (to report) and when something won't. You won't recognise that your baby is ugly because it has thousands of little things wrong with it if you don't report the thousands of little things. It's not often that you'll test a system where you find a "nose" in the completely wrong place, or an "ear" where an "eye" should be (to continue the 'baby' analogy). Those moments are easy - you *have* to risk the insult or risk completely failing to meet the customers' (and other stakeholders') needs.
If you test, and report bugs, in a way so as to "not offend" (i.e. by watering down the message, not testing certain features too hard, or choosing not to report certain bugs) are you really providing a helpful service?
What are you willing to risk to ensure clarity on your projects? What do you think?
Subscribe to:
Posts (Atom)