A common theme at conferences and workshops is "tell a story" - so here we go.
Once upon a time, there was a software project. This project had a variety of components, some were better understood than others. As sometimes happens, information was presented decisions were made in discussions where not all the interested parties are present. In this case, the testers were wrapping up another project and others involved in this one made the decision that testers weren't really "needed" yet.
So, life went on. The testers finished their project. They were given copies of the documents that had been prepared on this project. So they read the documents and worked on their own documents, like test plans and test cases. More meetings happened and conversations happened and emails were sent and read and replied to (well, were certainly replied to, maybe they were read by everyone.) Some of these had everyone present or copied or included, and some did not.
When the intrepid testing folks compared notes on an item described in the requirements documentation, they realized their understanding on did not match. No problem! They asked the tech lead to clarify what the correct interpretation should be. The answer? Neither was correct. And he explained why.
He then decided to verify what he had reported and brought the question to the business experts. Their answer consisted of "Well, everyone knows what that means..." and then they realized they each "business expert" had a different understanding of this very, basic element of their requirements.
No one had thought to define the terms. Then, to make it worse, no one had asked what the terms meant. It is possible that each participant believed they shared a common understanding. However, no one made sure that was the case.
I was not part of this project. It strikes me that most people fall into this trap at least once. Sometimes, twice.
Always question your unquestionable facts. They may not be as factual as you presume.
Sunday, June 13, 2010
Monday, June 7, 2010
Stawberry Testing Fields
Yesterday I wrote about the garden. We really have a nice one. I learn a lot working in it.
There is a rhythm in gardening that simply can't be ignored. Brute force and frantic bursts of energy don't get you much. Patience is good, and persistence.
Strawberries are coming in right now. We picked the first two this past Thursday. More were ripe on Friday. Saturday there were more. Last night I picked a couple of pints of berries. We have enough on the vine to have a fair crop of berries this year.
This is great, because we put in a new strawberry patch last year, replacing the old one. Its not huge, around 6 feet long, semi-circular, around 3 or 4 feet wide at its widest point. The old one was huge for a city lot. Almost 20'x20'. Unfortunately, when the new driveway was put in, the berry patch had to go. We did move the topsoil to a great location. This had been worked and improved for many, many years and was fantastic for growing things.
Last year, we planted tomatoes in that soil, as we had the year before. Oops. No tomatoes there this year thanks to the blight.
BUT - the new strawberry patch is doing extremely well.
As I was picking berries last night, my dear lady-wife made the observation that sometimes beautiful ripe berries will "hide" under the leaves or tucked out of the way. So, as I was carefully going through picking what I could find, it dawned on me that shifting leaves and plants may help, or may not.
Something struck me though. As I was working in one area, I looked over toward where I had just been working, I saw three lovely ripe berries - right where I had decided I had found everything that was ripe and moved on.
In shifting my view, my perspective, I found three berries where a moment before I absolutely "knew" there were none ripe.
It dawned on me then and there, that the challenge in finding bugs is overcoming our own solid "knowing" that we have finished. If you change your perspective, and look again, are you still finished?
Does this shift in perspective reveal you things you did not know? Are there items you may not have considered? In shifting your view do you find bugs you would have missed?
There is a rhythm in gardening that simply can't be ignored. Brute force and frantic bursts of energy don't get you much. Patience is good, and persistence.
Strawberries are coming in right now. We picked the first two this past Thursday. More were ripe on Friday. Saturday there were more. Last night I picked a couple of pints of berries. We have enough on the vine to have a fair crop of berries this year.
This is great, because we put in a new strawberry patch last year, replacing the old one. Its not huge, around 6 feet long, semi-circular, around 3 or 4 feet wide at its widest point. The old one was huge for a city lot. Almost 20'x20'. Unfortunately, when the new driveway was put in, the berry patch had to go. We did move the topsoil to a great location. This had been worked and improved for many, many years and was fantastic for growing things.
Last year, we planted tomatoes in that soil, as we had the year before. Oops. No tomatoes there this year thanks to the blight.
BUT - the new strawberry patch is doing extremely well.
As I was picking berries last night, my dear lady-wife made the observation that sometimes beautiful ripe berries will "hide" under the leaves or tucked out of the way. So, as I was carefully going through picking what I could find, it dawned on me that shifting leaves and plants may help, or may not.
Something struck me though. As I was working in one area, I looked over toward where I had just been working, I saw three lovely ripe berries - right where I had decided I had found everything that was ripe and moved on.
In shifting my view, my perspective, I found three berries where a moment before I absolutely "knew" there were none ripe.
It dawned on me then and there, that the challenge in finding bugs is overcoming our own solid "knowing" that we have finished. If you change your perspective, and look again, are you still finished?
Does this shift in perspective reveal you things you did not know? Are there items you may not have considered? In shifting your view do you find bugs you would have missed?
Gardening
We have a fairly large garden. Actually, my lady-wife has a large garden and I'm the helper. This works out pretty well for both of us. She gets more work done than she could do herself, and I get something interesting that can sometimes be missing when working in some software shops: a specific, tangible result from your efforts.
In some places I've worked, projects are never really "done." You finish one project and the next is, well, more modifications to the same application. The result is, you are never really "done."
Gardening isn't like that. You work for four or five, or more, hours in a day and you can see what you have accomplished. You can see clearly defined areas without weeds, flowers, maybe vegetables, but always something you can look at and say "I did that today."
This weekend was a great example. Saturday morning there were some big, ugly nasty weeds growing along the fenceline, near where the vegetable garden goes. We got well over half of the weeds dug or pulled. By the time we had made it that far, the sun was pretty hot, so work shifted to a shady area in another part of the year. While we did not finish that portion on Saturday, the work that remains can be finished in another good day's work. The list is fairly simple: finish pulling the weeds; till the garden; hoe it back into rows. Then we can plant again.
Last year's rows are still visible. This is part of the garden's version of a "legacy" system. The footprint of last year is there. The problem is, sometimes that can make more work.
Where we are, and a fair portion of the state and region, tomatoes had a blight last year. This was a fungal infection, related to the same blight that caused the potato famine in Ireland in the 1840's. The relationship is the spores from the fungus. Because the spores are found where the plants were last year, there is a problem with the "legacy system" - we can't put the tomatoes where we have in the past. We also need to get them as far away from where they had been as we can get them.
The solution was pretty simple. Spores are contained in the ground. To keep the tomatoes from getting blight keep them from coming in contact with the spores. So, as with most of the really good ideas in the garden - well, all of them, my lady-wife came up with a solution. Pots. Lots of pots. Large pots. Lots of very large pots. In a sunny spot with no contact with the soil that may have blight spores. The top of the driveway, of course. Hot and sunny, good for tomatoes. Near the rain barrels so easy watering. Tomatoes like a lot of water, so this is good for both them and us.
Moral of the story? Just because you've "always done things this way," does not mean that another is available - particularly if the solution presents itself.
Have you ever noticed that the solution "presenting itself" usually happens when you need to completely change the rules? How often can we make the rules change in what we do with software? Beets me. Lettuce try.
In some places I've worked, projects are never really "done." You finish one project and the next is, well, more modifications to the same application. The result is, you are never really "done."
Gardening isn't like that. You work for four or five, or more, hours in a day and you can see what you have accomplished. You can see clearly defined areas without weeds, flowers, maybe vegetables, but always something you can look at and say "I did that today."
This weekend was a great example. Saturday morning there were some big, ugly nasty weeds growing along the fenceline, near where the vegetable garden goes. We got well over half of the weeds dug or pulled. By the time we had made it that far, the sun was pretty hot, so work shifted to a shady area in another part of the year. While we did not finish that portion on Saturday, the work that remains can be finished in another good day's work. The list is fairly simple: finish pulling the weeds; till the garden; hoe it back into rows. Then we can plant again.
Last year's rows are still visible. This is part of the garden's version of a "legacy" system. The footprint of last year is there. The problem is, sometimes that can make more work.
Where we are, and a fair portion of the state and region, tomatoes had a blight last year. This was a fungal infection, related to the same blight that caused the potato famine in Ireland in the 1840's. The relationship is the spores from the fungus. Because the spores are found where the plants were last year, there is a problem with the "legacy system" - we can't put the tomatoes where we have in the past. We also need to get them as far away from where they had been as we can get them.
The solution was pretty simple. Spores are contained in the ground. To keep the tomatoes from getting blight keep them from coming in contact with the spores. So, as with most of the really good ideas in the garden - well, all of them, my lady-wife came up with a solution. Pots. Lots of pots. Large pots. Lots of very large pots. In a sunny spot with no contact with the soil that may have blight spores. The top of the driveway, of course. Hot and sunny, good for tomatoes. Near the rain barrels so easy watering. Tomatoes like a lot of water, so this is good for both them and us.
Moral of the story? Just because you've "always done things this way," does not mean that another is available - particularly if the solution presents itself.
Have you ever noticed that the solution "presenting itself" usually happens when you need to completely change the rules? How often can we make the rules change in what we do with software? Beets me. Lettuce try.
Friday, May 14, 2010
CASTing About for Food and Things to do in Grand Rapids
I got a message from some folks I know who are attending CAST asking about places to stay and places to eat. That got me thinking, and then typing...
Right out the gate - Traffic Warning! I-196 – the interstate highway that runs East-West through Grand Rapids has major construction going on and is CLOSED in fairly vital parts of downtown Grand Rapids. All the regular downtown traffic is being re-routed down Fulton Street and Michigan Street – the original E-W thoroughfares in the city. This will certainly hinder any driving you wish to do to get to downtown GR or anything on the West side of the city.
Having said that – there are some pretty cool things to do when you’re not CASTing…
Sunday, August 1 – Music Session - 7:00 PM to 9:00 PM
The location alternates between two spots within a block of each other in downtown Grand Rapids. I believe that August 1 will be at McFadden’s Restaurant, 58 Ionia SW. If I’m wrong, the session is at Tavern on the Square, located at 100 Ionia SW . Generally the music is Irish Traditional, with a smattering of Scottish, Cape Breton, Bluegrass and Old Timey, depending on who is there. Experience level of players tends to range from beginner to reasonably advanced and is open to anyone to play or listen. Both locations have drink specials – McFadden’s carries the Guinness/Smithwicks/Harp line-up with domestic beers as well. The Tavern has a nice selection of micro- and artisan beers, including some locally produced, along with food specials for Sunday night.
Every Day the week of CAST
The Frederic Meijer Gardens and Sculpture Park is a short drive up the road from the Prince Conference Center. Through September, they are hosting an exhibit of the work of Dale Chihuly, an artist who works in glass. Well, that’s a bit of an understatement. The exhibit is astounding. More information on the Gardens and the show can be had at their website. They are open until 9:00 PM Mondays and Tuesdays and until 5:00 PM other days.
Wednesday night
A local “collection” (chain is such a wrong term for them) of restaurants runs a special called “Wine Down Wednesday” where all wine from their “glass lists” is half off their regular price. Although owned and operated by the same group, each establishment has their own specialties and really, really commendable items. The nearest installment is The Blue Water Grill. They are a very short drive from the Prince Conference Center and is easily accessible from, well, the whole city. The largest establishment is downtown – The B.O.B. (Big Old Building) – that houses several individual eateries (and drinkeries.)
Other Non-Chain Eateries
One of my favorites is a neighborhood place on the West side of the city, a short distance from Michigan Street (which turns into Bridge Street when you cross the Grand River on, well, a bridge.) Salvatore’s has some very respectable pizza (my favorite is the “Taste of G.R.”) and a variety of typical “Italian” offerings based on the family’s recipes from Sicily. Not a fancy place, but reasonable prices and comfortable environment.
Where to stay?
Beats me - I can’t tell you the best places – I live in a house in the city! However! There are a bunch of hotels, some major name brands, some less so, within 15 or 20 minutes from the Prince Conference Center. There is a Country Inn & Suites that is fairly new a short distance from the Conference Center. About the same distance, and close to a couple of shopping malls, is a Residence Inn. Right in the same area is a Ramada Inn, although this is in a renovated, former Holiday Inn, so not a terribly new hotel. There is also a Staybridge Suites and a Fairfield Inn in the same general area. Those are the ones that are pretty much the closest to the conference location.
Right out the gate - Traffic Warning! I-196 – the interstate highway that runs East-West through Grand Rapids has major construction going on and is CLOSED in fairly vital parts of downtown Grand Rapids. All the regular downtown traffic is being re-routed down Fulton Street and Michigan Street – the original E-W thoroughfares in the city. This will certainly hinder any driving you wish to do to get to downtown GR or anything on the West side of the city.
Having said that – there are some pretty cool things to do when you’re not CASTing…
Sunday, August 1 – Music Session - 7:00 PM to 9:00 PM
The location alternates between two spots within a block of each other in downtown Grand Rapids. I believe that August 1 will be at McFadden’s Restaurant, 58 Ionia SW. If I’m wrong, the session is at Tavern on the Square, located at 100 Ionia SW . Generally the music is Irish Traditional, with a smattering of Scottish, Cape Breton, Bluegrass and Old Timey, depending on who is there. Experience level of players tends to range from beginner to reasonably advanced and is open to anyone to play or listen. Both locations have drink specials – McFadden’s carries the Guinness/Smithwicks/Harp line-up with domestic beers as well. The Tavern has a nice selection of micro- and artisan beers, including some locally produced, along with food specials for Sunday night.
Every Day the week of CAST
The Frederic Meijer Gardens and Sculpture Park is a short drive up the road from the Prince Conference Center. Through September, they are hosting an exhibit of the work of Dale Chihuly, an artist who works in glass. Well, that’s a bit of an understatement. The exhibit is astounding. More information on the Gardens and the show can be had at their website. They are open until 9:00 PM Mondays and Tuesdays and until 5:00 PM other days.
Wednesday night
A local “collection” (chain is such a wrong term for them) of restaurants runs a special called “Wine Down Wednesday” where all wine from their “glass lists” is half off their regular price. Although owned and operated by the same group, each establishment has their own specialties and really, really commendable items. The nearest installment is The Blue Water Grill. They are a very short drive from the Prince Conference Center and is easily accessible from, well, the whole city. The largest establishment is downtown – The B.O.B. (Big Old Building) – that houses several individual eateries (and drinkeries.)
Other Non-Chain Eateries
One of my favorites is a neighborhood place on the West side of the city, a short distance from Michigan Street (which turns into Bridge Street when you cross the Grand River on, well, a bridge.) Salvatore’s has some very respectable pizza (my favorite is the “Taste of G.R.”) and a variety of typical “Italian” offerings based on the family’s recipes from Sicily. Not a fancy place, but reasonable prices and comfortable environment.
Where to stay?
Beats me - I can’t tell you the best places – I live in a house in the city! However! There are a bunch of hotels, some major name brands, some less so, within 15 or 20 minutes from the Prince Conference Center. There is a Country Inn & Suites that is fairly new a short distance from the Conference Center. About the same distance, and close to a couple of shopping malls, is a Residence Inn. Right in the same area is a Ramada Inn, although this is in a renovated, former Holiday Inn, so not a terribly new hotel. There is also a Staybridge Suites and a Fairfield Inn in the same general area. Those are the ones that are pretty much the closest to the conference location.
Thursday, May 6, 2010
Listening Vs. Hearing
Yesterday I wrote about the role of Testers and how Testers should listen. Pretty straight forward, no? Just listen. Simple.
I find the challenge to be actually listening for what is said. Not for what you think is being said or what you want to hear.
Did you ever play "The Telephone Game"? The one where a person whispers a sentence to another person, then they pass the message on to the next person. They tell the next person and it goes on until it gets back to the first person.
Usually, well, pretty much always, there is no resemblance to the original sentence.
Our challenge - Our biggest problem - is making sure that the message that we are hearing is what is really being said.
I recently had the opportunity to play a testing game with some other testers. Not the dice games of Michael Bolton (and others) and not the card game of Lynn McKee and Nancy Kelln. This game was a simple word game.
I gave clues to a puzzle and then had them ask Yes/No questions around those clues to get the solution. These testers did eventually get the correct answer.
The interesting thing was that when they repeated the puzzle, they stated it differently. It wasn't wrong, just, different. Things that were actually answers to questions were integrated into the "original clues." This changed the dynamic of the puzzle slightly, but not terribly.
It struck me that if a simple game like this can go awry, how much easier is it to get requirements or "business purpose" wrong when you may not be terribly familiar with the field or industry? Can we, as testers, test our own suppositions about what is "right" to the point where we can arrive at the same conclusion of the need as those on whose behalf we are working?
I find the challenge to be actually listening for what is said. Not for what you think is being said or what you want to hear.
Did you ever play "The Telephone Game"? The one where a person whispers a sentence to another person, then they pass the message on to the next person. They tell the next person and it goes on until it gets back to the first person.
Usually, well, pretty much always, there is no resemblance to the original sentence.
Our challenge - Our biggest problem - is making sure that the message that we are hearing is what is really being said.
I recently had the opportunity to play a testing game with some other testers. Not the dice games of Michael Bolton (and others) and not the card game of Lynn McKee and Nancy Kelln. This game was a simple word game.
I gave clues to a puzzle and then had them ask Yes/No questions around those clues to get the solution. These testers did eventually get the correct answer.
The interesting thing was that when they repeated the puzzle, they stated it differently. It wasn't wrong, just, different. Things that were actually answers to questions were integrated into the "original clues." This changed the dynamic of the puzzle slightly, but not terribly.
It struck me that if a simple game like this can go awry, how much easier is it to get requirements or "business purpose" wrong when you may not be terribly familiar with the field or industry? Can we, as testers, test our own suppositions about what is "right" to the point where we can arrive at the same conclusion of the need as those on whose behalf we are working?
Wednesday, May 5, 2010
Requirements and Listening
At the QUEST conference in Dallas, there were many presentations, exercises and discussions around testers and requirements. Along with stressing the importance of requirements to project success, a regular theme was getting testers involved early in the project to help get the requirements “right.”
What was not often discussed was how the testers were to actually help get the requirements “right.” The problem, as I see it, is that there is not a clearly defined argument that can explain to me how being a good “tester” automatically makes a person a good “requirements definer.”
There were a couple of points made that people may have missed. One was part of a hall conversation -unfortunately I don’t recall who made it. This fellow's point was that the testers needed to do more than simply insist on “testable” requirements. Without being able to bring something to the discussion – without being able to help define the requirements, what purpose does a tester really serve at the discussion?
Nancy Kelln gave a presentation on testing in an Agile environment. It was interesting watching some of the attendees grappling with some of the basic premises found in a variety of Agile methodologies. While talking about Stand-ups, she answered the above question very succinctly. She said, in essence, the role of the tester in an Agile Stand-up, is to listen.
Simple, no? Its what all of us are supposed to do anyway, but usually find ourselves thinking about other things for at least part of the time.
By listening – by hearing what is being said, the tester can gain insight into some of the reasoning or logic or problems that are being encountered. If a tester is listening critically, and thinking like a tester, they can hear not only what is being said, but can hear what is not being said.
The thing is, most people who do not work in an Agile environment would argue something like "Well, that's Agile. We don't do Agile." You don't need to work in an Agile environment to do this. At Requirements reviews, or better yet, Requirements gathering/discovery meetings - the same technique can work: listen.
Listen critically, then, don't be afraid to ask questions. These questions can sometimes be straightforward. For example “We’ve talked about regulations changing around Y. Are there any regulations we need to consider for X?"
How many times have you been in a conversation and asked a question because you were looking for insight, and the person you asked it of had an "Ah-HA!" moment because of it? They realized that something was missing and there was an unconsidered possibility or gap.
By asking questions of the experts, the tester can clarify their own thoughts and maybe trigger others to also ask questions. Sometimes, the strength of not knowing things is asking questions and listening carefully to the answers.
What was not often discussed was how the testers were to actually help get the requirements “right.” The problem, as I see it, is that there is not a clearly defined argument that can explain to me how being a good “tester” automatically makes a person a good “requirements definer.”
There were a couple of points made that people may have missed. One was part of a hall conversation -unfortunately I don’t recall who made it. This fellow's point was that the testers needed to do more than simply insist on “testable” requirements. Without being able to bring something to the discussion – without being able to help define the requirements, what purpose does a tester really serve at the discussion?
Nancy Kelln gave a presentation on testing in an Agile environment. It was interesting watching some of the attendees grappling with some of the basic premises found in a variety of Agile methodologies. While talking about Stand-ups, she answered the above question very succinctly. She said, in essence, the role of the tester in an Agile Stand-up, is to listen.
Simple, no? Its what all of us are supposed to do anyway, but usually find ourselves thinking about other things for at least part of the time.
By listening – by hearing what is being said, the tester can gain insight into some of the reasoning or logic or problems that are being encountered. If a tester is listening critically, and thinking like a tester, they can hear not only what is being said, but can hear what is not being said.
The thing is, most people who do not work in an Agile environment would argue something like "Well, that's Agile. We don't do Agile." You don't need to work in an Agile environment to do this. At Requirements reviews, or better yet, Requirements gathering/discovery meetings - the same technique can work: listen.
Listen critically, then, don't be afraid to ask questions. These questions can sometimes be straightforward. For example “We’ve talked about regulations changing around Y. Are there any regulations we need to consider for X?"
How many times have you been in a conversation and asked a question because you were looking for insight, and the person you asked it of had an "Ah-HA!" moment because of it? They realized that something was missing and there was an unconsidered possibility or gap.
By asking questions of the experts, the tester can clarify their own thoughts and maybe trigger others to also ask questions. Sometimes, the strength of not knowing things is asking questions and listening carefully to the answers.
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)
