Thursday morning at TesTrek, in Toronto started with a keynote presentation by Michael Mah from QSM Associates on Offshoring, Agile Methods and the idea of a "Flat World." I could not stay as I was presenting in the first track session immediately following. My presentation on Integration Testing went over reasonably well, I thought. There were a fair number of people who were willing to participate and generally engage and some interesting discussion afterward.
To unwind, I went to Fiona Charles session on Test Strategy, She has given this as a full day workshop. Cramming it into a 90 minute session was challenging, but I thought gave a reasonable idea around the challenges of looking beyond templates and boilerplate.
I had a nice lunch conversation, again with Fiona and a handful of other people sitting around a table.
The balance of the day was a rush of impressions for me. I know the afternoon sessions occurred. Still, I found myself in interesting conversations with a people - many of whom I have named already. The thing is, without establishing relationships in the past, these conversations may not have happened.
Much of what I learn at conferences occurs in the "hallway track" - talking with people and discussing concepts of interest to us, whether they are on the program for the conference or not. There are a lot of people smarter than I am, with more experience than I have. The fun part for me is learning and sharing what I learn and have experienced.
The beauty of smaller conferences is that they give the intimacy that allows participants to meet a large number of people if they are willing to step outside of themselves. I can not encourage people enough to take advantage of that opportunity.
One thing that struck me was that I saw only a few people talking with other people they did not work with or know in advance. I'm always curious about that. The thing I consider to have been fortunate in is that I learned to swallow hard, overcome my shy, introspective tendencies and talk with people. Walk up, say "Hi, I'm Pete. Are you enjoying the conference? What have you been learning?" Sometimes it leads to interesting conversations.
Other times it is a little, less interesting. Folks say "Oh yeah, I have a session to go to. Maybe we can talk later." OK, no worries.
The thing is, I learned some time ago, and have blogged about it, that you need to allow time to talk with other people. It is a remarkable conference that has really significant, information-packed sessions in every time slot. Now, this is not a dig at TesTrek, don't get me wrong. I just find it interesting that there was not as much socializing/networking/confering as I saw. (There may have been more, in places I did not find, but I did not find or hear about them.)
I tweeted a few times inviting people to talk about anything to do with testing. Now, I had some fantastic conversations with Fiona, Adam Goucher, Tommas, Stephen and more. But what I found interesting was that of the tweets I sent out, the invitations (including the link to the blog post inviting people to confer at TesTrek) , resulted in one person saying "Are you Pete? I'm Heather! I saw your tweet!" That person was Heather Gardiner, with tulkita Technologies. We had a nice conversation, then we both had to deal with other things.
The thing is, and I think this holds for more testers, don't be afraid to meet and talk with other testers. Even folks like conference speakers, yeah, the "experts", like learning new things. You may not agree with them, and they may not agree with you. But, people who are thoughtful testers with a desire to learn and to share, are good sources for you to learn as well.
This, I think, is the great opportunity for people going to conferences: meeting people with a different viewpoint and learning. Smaller conferences, like TesTrek, give you the opportunity to meet people like you and have the chance to talk with every attendee.
Meet people. Talk with them. You never know what you might learn.
Showing posts with label TesTrek. Show all posts
Showing posts with label TesTrek. Show all posts
Friday, November 18, 2011
Thursday, November 17, 2011
Thoughts from TesTrek 2011 - Part 1
Last week I was in Toronto for the TesTrek Symposium hosted by Quality Assurance Institute. There were, what seemed to me, some 200 to 250 testers hanging out and talking about testing. In downtown Toronto. Cool.
So, I had the opportunity to spend time with people I had met briefly before the last two years I've been there. Yeah, it seems hard to believe this was my third TesTrek. Go figure.
The advantage of returning to the same conference, particularly if it is hosted in the same city, is you get to catch up and get to know other people you met there better than you can in a single meeting. In my case, I got to have a really nice series of conversations with both Tommas Marchese and Stephen Reiff - both of whom I met previously, but had the chance to spend time with each other, chat and learn.
Other people I see fairly frequently, mostly at other conferences, were Nancy Kelln, Adam Goucher, Fiona Charles. These folks are smart, capable testers. You hear a lot of marketing hype about "thought leaders" or "technical experts" or other buzzwords. You know what's really interesting? The people who are the real deal don't take those titles on themselves.
Monday and Tuesday at TesTrek consisted of a Manager's Workshop. This is an interesting model in that the participants break into groups and discuss topics of interest to, well, test managers. The times I've been involved in these workshops have been mentally invigorating, if not exhausting. This year, the day-job kind of got in the way so I could not attend and participate.
I drove to Toronto on Tuesday, checked into the hotel in Toronto, then went looking for the fun. I found the folks from the conference, like Darrin Crittenden and Nancy Kastl. I had the chance to sit down and have the first of many chats with Fiona and Tommas, and Nancy when she arrived from Calgary.
Wednesday opened with a "Pre-Keynote" by Tommas Marchese. His topic was "Heads Up Testers: Striving for Testing Excellence." In short, it was a call to action for testers to break out of the mold that some companies expect testers to stay in. He had several solid points and I thought it was an excellent start to the day.
The keynote following this, after all, this was a "pre-keynote" was a panel presentation with representatives from Microsoft, Micro Focus, HP and IBM-Rational. I did not find this an OK idea, and thought it would be better to have greater opportunity for audience participation, questions and the like.
The rest of the day was broken into workshop and presentation sessions. Tuesday these consisted of presentations around Test Measurement, Cloud Computing, Test Leadership, Security Testing and others. Nancy Kelln gave a workshop on Test Estimation that had originally been intended to be given along with her Partner-in-Crime/Conferences, Lynn McKee. She challenged people's expectations, just as I thought she might.
Tommas Marchese boldly gave a session on regression testing that he was not scheduled to give. Filling in and giving a presentation not your own can be a problem. He did a respectable job, I thought, and made some good points.
After the opening reception, with some more conversations, a handfull of us went to the Elephant & Castle around the corner for a quiet pint and conversation. I retired early to rest for the next day and prepare for my presentation.
So, I had the opportunity to spend time with people I had met briefly before the last two years I've been there. Yeah, it seems hard to believe this was my third TesTrek. Go figure.
The advantage of returning to the same conference, particularly if it is hosted in the same city, is you get to catch up and get to know other people you met there better than you can in a single meeting. In my case, I got to have a really nice series of conversations with both Tommas Marchese and Stephen Reiff - both of whom I met previously, but had the chance to spend time with each other, chat and learn.
Other people I see fairly frequently, mostly at other conferences, were Nancy Kelln, Adam Goucher, Fiona Charles. These folks are smart, capable testers. You hear a lot of marketing hype about "thought leaders" or "technical experts" or other buzzwords. You know what's really interesting? The people who are the real deal don't take those titles on themselves.
Monday and Tuesday at TesTrek consisted of a Manager's Workshop. This is an interesting model in that the participants break into groups and discuss topics of interest to, well, test managers. The times I've been involved in these workshops have been mentally invigorating, if not exhausting. This year, the day-job kind of got in the way so I could not attend and participate.
I drove to Toronto on Tuesday, checked into the hotel in Toronto, then went looking for the fun. I found the folks from the conference, like Darrin Crittenden and Nancy Kastl. I had the chance to sit down and have the first of many chats with Fiona and Tommas, and Nancy when she arrived from Calgary.
Wednesday opened with a "Pre-Keynote" by Tommas Marchese. His topic was "Heads Up Testers: Striving for Testing Excellence." In short, it was a call to action for testers to break out of the mold that some companies expect testers to stay in. He had several solid points and I thought it was an excellent start to the day.
The keynote following this, after all, this was a "pre-keynote" was a panel presentation with representatives from Microsoft, Micro Focus, HP and IBM-Rational. I did not find this an OK idea, and thought it would be better to have greater opportunity for audience participation, questions and the like.
The rest of the day was broken into workshop and presentation sessions. Tuesday these consisted of presentations around Test Measurement, Cloud Computing, Test Leadership, Security Testing and others. Nancy Kelln gave a workshop on Test Estimation that had originally been intended to be given along with her Partner-in-Crime/Conferences, Lynn McKee. She challenged people's expectations, just as I thought she might.
Tommas Marchese boldly gave a session on regression testing that he was not scheduled to give. Filling in and giving a presentation not your own can be a problem. He did a respectable job, I thought, and made some good points.
After the opening reception, with some more conversations, a handfull of us went to the Elephant & Castle around the corner for a quiet pint and conversation. I retired early to rest for the next day and prepare for my presentation.
Sunday, October 30, 2011
Conference Attendence 201 - Learning While Confering, Continued
I've written on this idea before. Here in fact. Many other people have written passionately about it as well. As I am fresh from presenting at STPCon Fall 2011 in Dallas and am getting my notes and reviewing my presentation for TesTrek 2011 (http://www.qaitestrek.org/2011/) in a couple weeks in Toronto, I wanted to take a moment and beat this drum one more time.
When you are at a conference, CONFER with people. Talk with them, ask question. Answer questions. Express opinions. Be open to learning. If you disagree with someone, let them know politely - and why. Maybe you are closer than you might realize and simply are stating the same thing different ways.
One really important point.
When the "official" sessions wind down and the "official" "networking opportunities" wrap up - look around for people just hanging from the conference. Then ask if you can join them. Ask what they do, where they do it, what they like about it. You may well learn really valuable ideas you can take back to the boss.
If you see a group of people from the conference sitting in the hotel bar/lounge/whatever, a quick scan will give you some idea of the conversation(s) going on. If it is vaguely related to software and/or testing, ASK IF YOU CAN JOIN THEM!
I know from my own experience, that if I have ANY energy left and no absolutely pressing duties elsewhere, I like to talk with other test professionals and learn. Yeah. I learn a lot just from talking with people. This last conference, I had some fantastic conversations with Doug Hoffman, Fiona Charles, Tony Bruce, Scott Barber, Dawn Haynes, Lanette Creamer, Catherine Powell, Robert Walsh, Dani Almog... the list goes on - Those are the folks that popped into my mind immediately. Testing Heavyweights all - and I gained insight, if not actionable information, from each conversation.
So, I invite any TesTrek Symposium attendee. If you see me sitting in a chair in the hallway sipping the web, or in the conference center lounge, please feel free to join me. Really. I like meeting people and sharing ideas, experiences and viewpoints.
I'm there to learn, too. Please help me learn.
When you are at a conference, CONFER with people. Talk with them, ask question. Answer questions. Express opinions. Be open to learning. If you disagree with someone, let them know politely - and why. Maybe you are closer than you might realize and simply are stating the same thing different ways.
One really important point.
When the "official" sessions wind down and the "official" "networking opportunities" wrap up - look around for people just hanging from the conference. Then ask if you can join them. Ask what they do, where they do it, what they like about it. You may well learn really valuable ideas you can take back to the boss.
If you see a group of people from the conference sitting in the hotel bar/lounge/whatever, a quick scan will give you some idea of the conversation(s) going on. If it is vaguely related to software and/or testing, ASK IF YOU CAN JOIN THEM!
I know from my own experience, that if I have ANY energy left and no absolutely pressing duties elsewhere, I like to talk with other test professionals and learn. Yeah. I learn a lot just from talking with people. This last conference, I had some fantastic conversations with Doug Hoffman, Fiona Charles, Tony Bruce, Scott Barber, Dawn Haynes, Lanette Creamer, Catherine Powell, Robert Walsh, Dani Almog... the list goes on - Those are the folks that popped into my mind immediately. Testing Heavyweights all - and I gained insight, if not actionable information, from each conversation.
So, I invite any TesTrek Symposium attendee. If you see me sitting in a chair in the hallway sipping the web, or in the conference center lounge, please feel free to join me. Really. I like meeting people and sharing ideas, experiences and viewpoints.
I'm there to learn, too. Please help me learn.
Friday, December 31, 2010
2010, A Retrospective
This year is drawing to an end. I know it is a tad lame to have a "look at the year that was" or any of the other cliche laden phrases that tend to be used to introduce these things.
The thing is, it has been an interesting year for me personally and professionally.
Let's see. General stuff. I retired the blog attached to my defunct drumming with bagpipe bands website. I replaced it with, this one. It had been in the "thinking about" phase for a long-time, and finally I decided to do it. Ya know what's interesting? As I think about other stuff - often Non-Testing stuff - something pops into my head about software development or testing or SOMETHING. Sometimes, that results in a blog post. Other times it leads to sitting in my big green comfy chair sipping a brandy and thinking.
Interesting work stuff at the day-job with interesting challenges early in the year. With a flurry of emails I found myself and the boss registered to attend QUEST in Dallas, Texas. This was a huge surprise to me as I was not expecting it at all, given limited budgets and going to TesTrek in Toronto the previous October. QUEST was interesting in that I met a number of people whose writings I had read, and had not met in real-life. I also got to connect with people I had met before and get back in touch in real-life.
May I received confirmation that I COULD attend CAST, which was being held around 15 minutes from my house - then in June it became clear that the scheduled release would conflict with attending CAST, so the company would neither pay the conference fee (something I was not too worried about) nor would they grant time-off. That one was a problem. July rolled around, schedules shifted again. I could be granted the time to go to CAST IF I was available during the conference. COMPROMISE! COOL!
Sunday evening of CAST had a great dinner and conversation with Fiona Charles and Griffin Jones and the lady-wife at a neighborhood Italian place. Recipes from Sicily and friendly folks and good wine and great conversation, little of it around testing, but all of it applicable to testing. What a great night.
Another night had a fantastic dinner out with a bunch of folks - Yeah, I know I blogged about that shortly after the event - it is still a great memory.
Dragged the boss in one evening to meet some of the great ones of the craft who would be there. Had a fantastic evening out with Nancy Kelln and Lynn McKee and the boss - more good wine (notice a trend?) and a great conversation.
Then, a bombshell was dropped that left me gob-smacked. It seems one of our dinner companions had a conflict and could not fulfill a speaking commitment in Toronto, would I be interested in being suggested as a an alternative speaker? Holy Cow. I thought about it briefly... and said Yes. One thing led to another and I did indeed speak at TesTrek in Toronto that October. Yeah, I blogged about that, too.
Stuff at the day-job continued to be interesting - meaning, really, really, busy.
So, things progressed. Talked with the boss about some interesting emails. The result of those chats was submitting proposals to a couple of conferences. I submitted proposals for a session similar to the session at TesTrek, but with a more advanced perspective than the general view there. The exciting thing was that the boss and I submitted a proposal for a joint presentation based on our experiences starting a QA/Testing team from scratch.
One conference said "no thanks" (although the boss was asked to consider a presentation in a different area) the other accepted both proposals! Yeah, that rocks. I get to hang with the cool kids at STPCon in Nashville this coming March.
More projects were successfully rolled out at the day job. There are some interesting things that seem to be happening there, they may lead to more ideas on blog posts.
The local testing group and its attempts spread its wings and fly has been great fun to watch and be a part of. Through it, I've met some terrific people, like Matt Heusser and Melissa Bugai , and have had fun sharing the adventure with them.
At home it was a good year in the garden. We had a good crop of strawberries and peppers and tomatoes, although some of the others were a little surprising in what were less prolific than expected. Several big projects got done - and inspired thoughts about, then blog posts about, software and testing.
We had some sadness in our lives this year. Stuff that led to serious rounds of soul-searching for "what is this all about." We also have had some great joys in our lives this year. For that, I am grateful. I don't know what 2011 will bring, but I am looking forward to the next year.
The thing is, it has been an interesting year for me personally and professionally.
Let's see. General stuff. I retired the blog attached to my defunct drumming with bagpipe bands website. I replaced it with, this one. It had been in the "thinking about" phase for a long-time, and finally I decided to do it. Ya know what's interesting? As I think about other stuff - often Non-Testing stuff - something pops into my head about software development or testing or SOMETHING. Sometimes, that results in a blog post. Other times it leads to sitting in my big green comfy chair sipping a brandy and thinking.
Interesting work stuff at the day-job with interesting challenges early in the year. With a flurry of emails I found myself and the boss registered to attend QUEST in Dallas, Texas. This was a huge surprise to me as I was not expecting it at all, given limited budgets and going to TesTrek in Toronto the previous October. QUEST was interesting in that I met a number of people whose writings I had read, and had not met in real-life. I also got to connect with people I had met before and get back in touch in real-life.
May I received confirmation that I COULD attend CAST, which was being held around 15 minutes from my house - then in June it became clear that the scheduled release would conflict with attending CAST, so the company would neither pay the conference fee (something I was not too worried about) nor would they grant time-off. That one was a problem. July rolled around, schedules shifted again. I could be granted the time to go to CAST IF I was available during the conference. COMPROMISE! COOL!
Sunday evening of CAST had a great dinner and conversation with Fiona Charles and Griffin Jones and the lady-wife at a neighborhood Italian place. Recipes from Sicily and friendly folks and good wine and great conversation, little of it around testing, but all of it applicable to testing. What a great night.
Another night had a fantastic dinner out with a bunch of folks - Yeah, I know I blogged about that shortly after the event - it is still a great memory.
Dragged the boss in one evening to meet some of the great ones of the craft who would be there. Had a fantastic evening out with Nancy Kelln and Lynn McKee and the boss - more good wine (notice a trend?) and a great conversation.
Then, a bombshell was dropped that left me gob-smacked. It seems one of our dinner companions had a conflict and could not fulfill a speaking commitment in Toronto, would I be interested in being suggested as a an alternative speaker? Holy Cow. I thought about it briefly... and said Yes. One thing led to another and I did indeed speak at TesTrek in Toronto that October. Yeah, I blogged about that, too.
Stuff at the day-job continued to be interesting - meaning, really, really, busy.
So, things progressed. Talked with the boss about some interesting emails. The result of those chats was submitting proposals to a couple of conferences. I submitted proposals for a session similar to the session at TesTrek, but with a more advanced perspective than the general view there. The exciting thing was that the boss and I submitted a proposal for a joint presentation based on our experiences starting a QA/Testing team from scratch.
One conference said "no thanks" (although the boss was asked to consider a presentation in a different area) the other accepted both proposals! Yeah, that rocks. I get to hang with the cool kids at STPCon in Nashville this coming March.
More projects were successfully rolled out at the day job. There are some interesting things that seem to be happening there, they may lead to more ideas on blog posts.
The local testing group and its attempts spread its wings and fly has been great fun to watch and be a part of. Through it, I've met some terrific people, like Matt Heusser and Melissa Bugai , and have had fun sharing the adventure with them.
At home it was a good year in the garden. We had a good crop of strawberries and peppers and tomatoes, although some of the others were a little surprising in what were less prolific than expected. Several big projects got done - and inspired thoughts about, then blog posts about, software and testing.
We had some sadness in our lives this year. Stuff that led to serious rounds of soul-searching for "what is this all about." We also have had some great joys in our lives this year. For that, I am grateful. I don't know what 2011 will bring, but I am looking forward to the next year.
Sunday, October 24, 2010
TPI Presentation Summary
This post resulted from typing up the notes taken on flip-charts that I promised to type and send to the participants in the workshop I did at TesTrek in Toronto. My thanks go to all the people who were there and participated in the discussion, particularly Lynn McKee, Paul Carvalho, Michael Bolton, Michael... the other Michael who did not have business cards and whose last name I don't recall. That this session took the path it did, and that the quality of the discussion it had was due very largely, if not entirely, to you. I know I learned a great deal and I was the one with the microphone.
My notes:
Points made in discussion during presentation portion:
SWOT is a tool to look at your team’s Strengths and Weaknesses while being aware of external Opportunities and Threats – Things that you may be able to take advantage of and those things that may block your progress.
These items are from the ideas that were volunteered by participants.
Strengths
Technically Competent
Dedicated
Finds “Good Bugs” fast
Detail Oriented
Shows Craftsmanship / Professional Pride in work
Team Gels
Good Communication (and skills)
Understands Roles
Big Test Case Toolbox
Adaptable
Has the trust of peers and colleagues
Weaknesses
Hard to say “No”
Resistant to change
Low technical knowledge
Poor estimation skills
Staff not as good as they think they are
Lack of creativity
Summary
The conversation around these points was important and I allowed it to flow freely, believing that they bore greater value than walking through a planned exercise. It was interesting to note that the strengths were drawn out very quickly, while the weaknesses took nearly twice as long and ended with far fewer items.
This is almost exactly in line with my experiences with using this technique.
It is easy to state what a person or team is good at – what their strengths are. Getting this down to specifics from the more general terms can be a bit more challenging, but usually bears fruit. Saying out loud (admitting to yourself and your team) what the weaknesses and short comings are is far harder. We all have frames around ourselves that limit our vision. We all want to be heroes in our own minds – no one wants to be the villain. Most people want to believe they are good if not very good at what they do.
Getting your team together and discussing what the weaknesses the team has means at some point people must trust each other to help improve individual shortcomings. If your list of strengths includes something about “teamwork” and people are not able or are unwilling to be honest with each other (yes, you can be polite and honest at the same time) then the “teamwork” strength needs to be removed from the list.
The greatest single challenge is to face yourself as you are. This is compounded when attempting to do this with, and in front of, co-workers and team members. The leader/manager may need to get help in doing this very hard task, and to break down the barriers that exist to allow frank discussion to occur. Tempers may flare and nerves will certainly be on edge. The “trick” is to allow cooling-off periods. Perhaps meeting for a couple hours each day for a couple of weeks instead of reserving three or four days in a row to do nothing but this would make it easier. This will allow people to talk privately and do their own reality-checks on what happens, or should happen.
Sometimes, the most potent force in this process is to have people thinking about these topics in the back of their minds while working on their “real” work. While focusing on a challenge, don’t be surprised if something pops into your mind related to the SWOT discussions and how that revelation can bear on the next discussion session.
AND SO, in simple language:
• To improve your Test Process, you must improve your team’s testing.
• To improve your testing, you must have a solid understanding of what your team is capable of RIGHT NOW.
• To understand your team’s capability, you must understand your team’s Strengths and Weaknesses.
• If you understand the Strengths and Weaknesses, you can consider what it is that Management or Customers are expecting.
• Recognizing what Management and Customers are expecting becomes your first Opportunity.
• Recognizing Opportunity may reveal things that will block those opportunities: Threats.
• Engaging in this process with your entire team will demonstrate to your team how serious you are to improving the team and making the individuals better at what they do.
• When you make the testing itself better, the Testing Process will be improved.
My notes:
Test Process Improvement:
Lessons Learned from the Trenches
Flip-chart notes from TesTrek Conference, October 2010
Points made in discussion during presentation portion:
- (In looking at testing…) How do I add value? (Lynn McKee)
- Something’s wrong, Customers report “issues”
- What’s an issue?
- Issues may not be problems to everyone (Michael Bolton)
- Expectations don’t match somehow
- Problem in Requirements or Scope creep?
- Allow your team to make mistakes (Paul Carvalho)
- Nothing teaches more than failure…
- Understand why you are doing something…
SWOT is a tool to look at your team’s Strengths and Weaknesses while being aware of external Opportunities and Threats – Things that you may be able to take advantage of and those things that may block your progress.
These items are from the ideas that were volunteered by participants.
Strengths
Technically Competent
Dedicated
Finds “Good Bugs” fast
Detail Oriented
Shows Craftsmanship / Professional Pride in work
Team Gels
Good Communication (and skills)
Understands Roles
Big Test Case Toolbox
Adaptable
Has the trust of peers and colleagues
Weaknesses
Hard to say “No”
Resistant to change
Low technical knowledge
Poor estimation skills
Staff not as good as they think they are
Lack of creativity
Summary
The conversation around these points was important and I allowed it to flow freely, believing that they bore greater value than walking through a planned exercise. It was interesting to note that the strengths were drawn out very quickly, while the weaknesses took nearly twice as long and ended with far fewer items.
This is almost exactly in line with my experiences with using this technique.
It is easy to state what a person or team is good at – what their strengths are. Getting this down to specifics from the more general terms can be a bit more challenging, but usually bears fruit. Saying out loud (admitting to yourself and your team) what the weaknesses and short comings are is far harder. We all have frames around ourselves that limit our vision. We all want to be heroes in our own minds – no one wants to be the villain. Most people want to believe they are good if not very good at what they do.
Getting your team together and discussing what the weaknesses the team has means at some point people must trust each other to help improve individual shortcomings. If your list of strengths includes something about “teamwork” and people are not able or are unwilling to be honest with each other (yes, you can be polite and honest at the same time) then the “teamwork” strength needs to be removed from the list.
The greatest single challenge is to face yourself as you are. This is compounded when attempting to do this with, and in front of, co-workers and team members. The leader/manager may need to get help in doing this very hard task, and to break down the barriers that exist to allow frank discussion to occur. Tempers may flare and nerves will certainly be on edge. The “trick” is to allow cooling-off periods. Perhaps meeting for a couple hours each day for a couple of weeks instead of reserving three or four days in a row to do nothing but this would make it easier. This will allow people to talk privately and do their own reality-checks on what happens, or should happen.
Sometimes, the most potent force in this process is to have people thinking about these topics in the back of their minds while working on their “real” work. While focusing on a challenge, don’t be surprised if something pops into your mind related to the SWOT discussions and how that revelation can bear on the next discussion session.
AND SO, in simple language:
• To improve your Test Process, you must improve your team’s testing.
• To improve your testing, you must have a solid understanding of what your team is capable of RIGHT NOW.
• To understand your team’s capability, you must understand your team’s Strengths and Weaknesses.
• If you understand the Strengths and Weaknesses, you can consider what it is that Management or Customers are expecting.
• Recognizing what Management and Customers are expecting becomes your first Opportunity.
• Recognizing Opportunity may reveal things that will block those opportunities: Threats.
• Engaging in this process with your entire team will demonstrate to your team how serious you are to improving the team and making the individuals better at what they do.
• When you make the testing itself better, the Testing Process will be improved.
Monday, August 30, 2010
Learning and Teaching and Leading
One thing I learned early on when teaching drumming students, particularly beginners, is that the person who learns the most is often the teacher.
It never seems to matter whether the lesson is an individual or group lesson, focused on one style or general drumming - the process of teaching beginners forces the instructor to reconsider things that the instructor simply does. This forces the teacher to reconsider all that he does, find interesting foibles or potential weaknesses, then correct or change them as needed for working with the student.
The interesting thing is that this reflection sometimes leads to profound understanding of what the student is learning and what the instructor is conveying. When preparing for the odd lunch-and-learn or training session at the office I never really had that kind of an experience - or when presenting such sessions.
On Improvement...
This last couple of weeks something interesting happened. I've been preparing a presentation on Test Process Improvement for TesTrek in October. I wasn't scheduled to present, or lead a workshop, but as a couple of presenters had to cancel, Viola! I'm on the presenters list. Then, a couple of other things came into my observation.
There have been several conversations on email lists I'm a participant in, as well as forums, on the dreaded M word. Yes - Metrics.
On top of this, I had a remarkably revealing email conversation with Markus Gartner - amazingly bright guy. This came about because the questions I submitted for the "Ask the Tester" were submitted after the magic number of 10 had been reached. However, they were forwarded to Markus and that presented me the opportunity to learn and be rinded of things I once knew and had forgotten (or channelled off into a safe place in my memory.)
My question to Markus was centered on his take of "Test Process Improvement" in an Agile environment. The bulk of his response was reasonably close to what I expected - in fact, reassuringly close to what I had prepared for the presentation so my confidence level increased dramatically in what I was saying. (Yes, a little reassurance is sometimes a good thing, particularly when one is a very little fish hanging out with very big fish.)
He had one idea that I did not have. And it left me gob-smacked. Tacked onto an already interesting sentence about the organization's management, Markus said "... or they don't trust testing anymore."
On Trust...
I was immediately thrown back many years to when Developers were called Programmers and when I was working as a COBOL Programmer on a large IBM mainframe. I had a Manager who did not trust his staff. Not because they were inexperienced, but because he simply did not trust them. To this day, I do not know why that was the case. I can surmise why, but it has little to do with the point. Suffice to say, it was an un-happy work environment.
Markus made an interesting observation. His point was that in Agile, the very purpose is to engender trust amongst all participants. Additionally, when management is invited to observe the meetings, they can gain an understanding of what is being done by their staff and as their understanding increases, so to should their level of trust.
When a group or a team has lost the trust of its management, the task of regaining that trust is nigh-on insurmountable. Likewise, if a manager or lead has lost the trust of the group they are to lead or manage, the results will almost certainly be dire.
On Process...
Thus, when the call comes down for "better metrics" or "process improvement" or any other number of topics. What is the underlying message? What is it that someone is hoping to gain? Do they know? CAN they know? Are they guessing?
Much is debated around QUANTifiable and QUALifiable considerations, measurement and understanding. I am not nearly bright enough to join into that fray fully-fledged.
What I have seen, however, is when Managers, Directors, VPs, EVPs, and big-bosses of all varieties are looking for something - nearly anything will suffice. A depressing number of times, I have seen management groups flail around what is wanted - then issue and edict announcing the new policy or practice or whatever it is. These tend to roll-out like clockwork, every three to six months.
Each company where I have worked that followed that practice engendered a huge amount of cynicism, resentment and distrust. The sad thing is that these rather stodgy companies - including some that were quite small and prided themselves on having no Dilbert-esque Pointy-Haired-Boss behaviors - were wasting an amazing opportunity.
The first step to fixing a "problem" is figuring out what the problem is. If there is no understanding over why policies or procedures are changing and no feed-back loop on the purposes behind the changed, will the average rank-and-file worker stand up and say "What do you hope to change/improve/learn from this?" At some companies - maybe. But I have seen relatively few times where the combination of policy-dujour and staff willing to stick their necks out and ask questions both exist in the same organization.
On Leadership...
What I have learned, instead, is to look at all sources of information. Explain what the problem or perceived problem is. Ask for input - then consider it fairly. To do so is not a sign of weakness - it is a sign of strength. That the leadership of the organization have enough trust in their workers to approach them with a problem and work together toward a solution.
This, in my mind, is the essence of building a team.
If you throw a bunch of people together without a unifying factor and expect great things it is silly in the extreme. In the military, "Basic Training" serves this purpose - laying the groundwork to trust your comrades and follow the direction of officers and non-commissioned officers. In the end though, the object is teamwork: learning to work together using each persons strengths to off-set others weaknesses.
Why is it that so many managers miss this rather elementary point? For a team to "work" they must learn to work together. If the Lead or Manager has not built the group into one capable of working together, like a team, what, other than professional pride, will get any results at all?
Although I can not prove this, in a scientific method as it were, I suspect that it is the essence of the problem mentioned above. The question I do not know the answer to, although suspect it, is the question of leadership in this instance.
Is it that they, the leaders, have no idea how to build a team? Is it possible that the step of instructing the fledgling team and shaping it into the needed form was too challenging? Could it be that in the process of doing so, their own closely held beliefs, habits and foibles were more dear than the building of a successful team?
If this basic lack is present, does it contribute to the selection of what is easy over what is right?
These are the ideas that have been floating through my mind while preparing the presentation and workshop lessons for the session at TesTrek. If the master knows that he is but a beginner in the craft, what of those who consider themselves experts in all aspects of our trade.
Can this be at the root of the behaviours I've seen first hand and read about? Are they feeling so insecure in their own abilities that they mistrust their own staff, the team they are charged with leading? Is it to make up for this lack, they flounder and grasp for tips or magic revelations that will show them the "path?" Is that why there is a continuing and perpetual drive for Metrics and Process Improvement?
It never seems to matter whether the lesson is an individual or group lesson, focused on one style or general drumming - the process of teaching beginners forces the instructor to reconsider things that the instructor simply does. This forces the teacher to reconsider all that he does, find interesting foibles or potential weaknesses, then correct or change them as needed for working with the student.
The interesting thing is that this reflection sometimes leads to profound understanding of what the student is learning and what the instructor is conveying. When preparing for the odd lunch-and-learn or training session at the office I never really had that kind of an experience - or when presenting such sessions.
On Improvement...
This last couple of weeks something interesting happened. I've been preparing a presentation on Test Process Improvement for TesTrek in October. I wasn't scheduled to present, or lead a workshop, but as a couple of presenters had to cancel, Viola! I'm on the presenters list. Then, a couple of other things came into my observation.
There have been several conversations on email lists I'm a participant in, as well as forums, on the dreaded M word. Yes - Metrics.
On top of this, I had a remarkably revealing email conversation with Markus Gartner - amazingly bright guy. This came about because the questions I submitted for the "Ask the Tester" were submitted after the magic number of 10 had been reached. However, they were forwarded to Markus and that presented me the opportunity to learn and be rinded of things I once knew and had forgotten (or channelled off into a safe place in my memory.)
My question to Markus was centered on his take of "Test Process Improvement" in an Agile environment. The bulk of his response was reasonably close to what I expected - in fact, reassuringly close to what I had prepared for the presentation so my confidence level increased dramatically in what I was saying. (Yes, a little reassurance is sometimes a good thing, particularly when one is a very little fish hanging out with very big fish.)
He had one idea that I did not have. And it left me gob-smacked. Tacked onto an already interesting sentence about the organization's management, Markus said "... or they don't trust testing anymore."
On Trust...
I was immediately thrown back many years to when Developers were called Programmers and when I was working as a COBOL Programmer on a large IBM mainframe. I had a Manager who did not trust his staff. Not because they were inexperienced, but because he simply did not trust them. To this day, I do not know why that was the case. I can surmise why, but it has little to do with the point. Suffice to say, it was an un-happy work environment.
Markus made an interesting observation. His point was that in Agile, the very purpose is to engender trust amongst all participants. Additionally, when management is invited to observe the meetings, they can gain an understanding of what is being done by their staff and as their understanding increases, so to should their level of trust.
When a group or a team has lost the trust of its management, the task of regaining that trust is nigh-on insurmountable. Likewise, if a manager or lead has lost the trust of the group they are to lead or manage, the results will almost certainly be dire.
On Process...
Thus, when the call comes down for "better metrics" or "process improvement" or any other number of topics. What is the underlying message? What is it that someone is hoping to gain? Do they know? CAN they know? Are they guessing?
Much is debated around QUANTifiable and QUALifiable considerations, measurement and understanding. I am not nearly bright enough to join into that fray fully-fledged.
What I have seen, however, is when Managers, Directors, VPs, EVPs, and big-bosses of all varieties are looking for something - nearly anything will suffice. A depressing number of times, I have seen management groups flail around what is wanted - then issue and edict announcing the new policy or practice or whatever it is. These tend to roll-out like clockwork, every three to six months.
Each company where I have worked that followed that practice engendered a huge amount of cynicism, resentment and distrust. The sad thing is that these rather stodgy companies - including some that were quite small and prided themselves on having no Dilbert-esque Pointy-Haired-Boss behaviors - were wasting an amazing opportunity.
The first step to fixing a "problem" is figuring out what the problem is. If there is no understanding over why policies or procedures are changing and no feed-back loop on the purposes behind the changed, will the average rank-and-file worker stand up and say "What do you hope to change/improve/learn from this?" At some companies - maybe. But I have seen relatively few times where the combination of policy-dujour and staff willing to stick their necks out and ask questions both exist in the same organization.
On Leadership...
What I have learned, instead, is to look at all sources of information. Explain what the problem or perceived problem is. Ask for input - then consider it fairly. To do so is not a sign of weakness - it is a sign of strength. That the leadership of the organization have enough trust in their workers to approach them with a problem and work together toward a solution.
This, in my mind, is the essence of building a team.
If you throw a bunch of people together without a unifying factor and expect great things it is silly in the extreme. In the military, "Basic Training" serves this purpose - laying the groundwork to trust your comrades and follow the direction of officers and non-commissioned officers. In the end though, the object is teamwork: learning to work together using each persons strengths to off-set others weaknesses.
Why is it that so many managers miss this rather elementary point? For a team to "work" they must learn to work together. If the Lead or Manager has not built the group into one capable of working together, like a team, what, other than professional pride, will get any results at all?
Although I can not prove this, in a scientific method as it were, I suspect that it is the essence of the problem mentioned above. The question I do not know the answer to, although suspect it, is the question of leadership in this instance.
Is it that they, the leaders, have no idea how to build a team? Is it possible that the step of instructing the fledgling team and shaping it into the needed form was too challenging? Could it be that in the process of doing so, their own closely held beliefs, habits and foibles were more dear than the building of a successful team?
If this basic lack is present, does it contribute to the selection of what is easy over what is right?
These are the ideas that have been floating through my mind while preparing the presentation and workshop lessons for the session at TesTrek. If the master knows that he is but a beginner in the craft, what of those who consider themselves experts in all aspects of our trade.
Can this be at the root of the behaviours I've seen first hand and read about? Are they feeling so insecure in their own abilities that they mistrust their own staff, the team they are charged with leading? Is it to make up for this lack, they flounder and grasp for tips or magic revelations that will show them the "path?" Is that why there is a continuing and perpetual drive for Metrics and Process Improvement?
Saturday, May 1, 2010
Conference Mode
I recently returned from a week in Dallas for QAI's QUEST (Quality Engineering and Software Testing) conference. The first two days consisted of either tutorials or a "Managers Solutions Workshop." The next three days were track sessions, presentations, keynote addresses, meals, snacks, coffee, tea, juice and all the trimmings that most people associate with "large" conferences. Its natural, I suppose, to compare it to other experiences.
Last October I was at TesTrek in Toronto, also hosted by QAI. There, I had the distinct and exciting opportunity to meet in real-life two people whose articles, books, blogs, etc., I had read and learned a great deal from. When it dawned on my that the "Fiona" sitting next to me at breakfast was Fiona Charles, I was, well, excited. A few minutes later, Michael Bolton sat down at the same table and struck up a lively conversation (as always!) This was 8:00 Monday morning - the first day of the conference! What a way to start the week!
Later in the week, Michael grabbed me for a round of "testing games" - yes, his case of dice came out and we went to it. In the course of the game, conversation touched on many, many topics, as these things tend to do. Soon, there was a table full of people engaged in ideas on metrics, measurement, performance, general testing. The dice were set aside and introductions made round.
That is when I met Lynn McKee and Nancy Kelln, from Calgary. They were also presenting at TesTrek - and struck me as smart, well spoken, up-and-coming testing and agile practitioners and speakers. We had a wonderful conversation then, and touched base the rest of the week. When the opportunity came to attend QUEST came up, I was excited to hear Lynn and Nancy give their presentations.
My boss/immediate supervisor went with me. We met Lynn and Nancy early on in the week and agreed to meet again for dinner and more testing games over the course of the week.
On Thursday morning, as my boss and I were having breakfast, we compared notes on our impressions thus far. I thought it was interesting how similar our own views were.
In short, it bore out my belief that the most important part of conferences is meeting people and building relationships with colleagues, and maybe developing those relationships into friendships. Don't tell conference planners this, but I find some conference presentations to be less about sharing information and experiences, than they are about the "sales pitch" for their product. (I make a habit of not sticking around for those presentations.)
Don't get me wrong - I like the "roundtable" format of the Managers Workshops at TesTrek and Quest. It allows peers to compare notes on problems that are confronting them right then. I like the presentations that describe "real world" problems and experiences.
Mostly though, I like sitting down with people who do what I do and compare notes:
"Conference Mode" absolutely rocks.
Last October I was at TesTrek in Toronto, also hosted by QAI. There, I had the distinct and exciting opportunity to meet in real-life two people whose articles, books, blogs, etc., I had read and learned a great deal from. When it dawned on my that the "Fiona" sitting next to me at breakfast was Fiona Charles, I was, well, excited. A few minutes later, Michael Bolton sat down at the same table and struck up a lively conversation (as always!) This was 8:00 Monday morning - the first day of the conference! What a way to start the week!
Later in the week, Michael grabbed me for a round of "testing games" - yes, his case of dice came out and we went to it. In the course of the game, conversation touched on many, many topics, as these things tend to do. Soon, there was a table full of people engaged in ideas on metrics, measurement, performance, general testing. The dice were set aside and introductions made round.
That is when I met Lynn McKee and Nancy Kelln, from Calgary. They were also presenting at TesTrek - and struck me as smart, well spoken, up-and-coming testing and agile practitioners and speakers. We had a wonderful conversation then, and touched base the rest of the week. When the opportunity came to attend QUEST came up, I was excited to hear Lynn and Nancy give their presentations.
My boss/immediate supervisor went with me. We met Lynn and Nancy early on in the week and agreed to meet again for dinner and more testing games over the course of the week.
On Thursday morning, as my boss and I were having breakfast, we compared notes on our impressions thus far. I thought it was interesting how similar our own views were.
In short, it bore out my belief that the most important part of conferences is meeting people and building relationships with colleagues, and maybe developing those relationships into friendships. Don't tell conference planners this, but I find some conference presentations to be less about sharing information and experiences, than they are about the "sales pitch" for their product. (I make a habit of not sticking around for those presentations.)
Don't get me wrong - I like the "roundtable" format of the Managers Workshops at TesTrek and Quest. It allows peers to compare notes on problems that are confronting them right then. I like the presentations that describe "real world" problems and experiences.
Mostly though, I like sitting down with people who do what I do and compare notes:
- How do you help people break away from this approach and introduce other, alternative ideas to them?
- When you were working on the transition to Scrum what did you encounter with folks whose experience was more rigid and less nimble?
- When you were trying to develop metrics that mean something to developers and testers, how did you implement that in a way them so they saw them as a tool for their improvement and not a threat to them or their position?
"Conference Mode" absolutely rocks.
Subscribe to:
Posts (Atom)
