I haven't had much time for blogging lately. A few great, interesting, cool things that are swamping me right now -
- Jim Brosseau's Book, "Taking Ownership"is completely through the greenlight stage and moving to publication. Yaaay!
- I'm speaking at the Grand Rapid's Java User's Group on Tuesday the 18th of September. They literally sent out a call for speaker's last week, and I responded that I had a couple of lightning talks that I think might string together well for ten or fifteen minutes. So they asked me for an abstract for a full talk ... it should be interesting.
- I'm coaching a team of 4 and 5 year old children from Allegan AYSO Soccer. GO ALLEAN TEAM FIVE SILLY FROGS!
- I'm serving as a volunteer and a speaker for GLSEC this year.
More about GLSEC next post, but for the time being, let's just say I've been busy ...
Showing posts with label Presentations. Show all posts
Showing posts with label Presentations. Show all posts
Friday, September 14, 2007
Monday, July 16, 2007
Something old ...
I just got back from the wedding of a collegue.
In that spirit, I am reminded of the talk I gave last year at the Indiana Quality Conference - something James Bach recently refered to as a "Kick-Ass Podcast." (No really, his words, not mine.)
It's at the very bottom of the stack for Creative Chaos, so I thought I would let it bubble up -
The title is "So You're Doomed" - Here's a link to the PowerPoint (5MB)
And the Audio (45MB).
The audio is forty-five-ish minutes. I look forward to your feedback!
In that spirit, I am reminded of the talk I gave last year at the Indiana Quality Conference - something James Bach recently refered to as a "Kick-Ass Podcast." (No really, his words, not mine.)
It's at the very bottom of the stack for Creative Chaos, so I thought I would let it bubble up -
The title is "So You're Doomed" - Here's a link to the PowerPoint (5MB)
And the Audio (45MB).
The audio is forty-five-ish minutes. I look forward to your feedback!
Tuesday, June 05, 2007
Conferences - V
I promised to detail my strategy to start attending conferences.
Actually, it's pretty simple.
1) Get involved in a local user's group. Meet colleagues, discuss ideas, help other people solve their problems, give presentations and/or join the leadership team. If you don't have a local user's group, found one. (No, it is not that hard - I founded the Grand Rapid Perl Mongers in 1998, a user's group that is still around. How to do that is a different post.)
Sidebar:
The value in the user's group is networking, but I disagree with a lot of people about networking. Some think it is about collecting a large rolodex or making acquaintances to 'get' a job or contract. Well, that might work; there are specific techniques people use to jump from lead to lead.
Personally, I don't buy it. Why would anyone want to connect to a leach? To network effectively, you need to get to know other people at least well enough to know what they are interested in. Once you do that, you listen to the problems they have and see if you can help. Eventually, people in your network will look forward to calls from you because they know you will be offering to help them in some way - or at least have something interesting to discuss. Perhaps, some day, a sense of reciprocity kicks in, and they mention an opportunity for you. Perhaps not. The point is, now a lot of people know you and your reputation grows.
---> And you'll use that sidebar reputation in step two.
2) Put your local reputation to good use:
You could ...
2a) Look for a regional conference or a national conference in your area.
If you live in a big city like Chicago, Indianapolis, Denver, or Portland you are sure to find a regional conference staffed by volunteers. This conference is probably close enough that there will be no travel costs and no hotel costs. It will be short enough that you can miss a day or two - a max of three days - not a week. And you can get in free in two different
ways; you can either speak or volunteer to help run the conference.
For that matter, there are a lot of big national conferences that are in the same place every year, like the Twin Cities, Minnesota area, the Orlando Florida Area, the Boston Area, SanFranciso , Orange County California, and so on. Again, you can get in by either speaking or, in many cases, even the big conferences allow a limited number of volunteer slots. Also, the big conferences may be as long as a week, but you can usually sign up for "Just the conference days" or "Just the tutorial days" and only miss three or four days of work.
If you live in the United States or Canada and can't find a local conference, drop a comment on my blog and I will see what I can do.
2b) Eventually, someone in your user's group will know someone else who is hiring. And if you are an active member of the group, they will have some ability to evaluate you, and possibly recommend you. So here's the secret: Go to a company that regularly sends it's technology employees to training. Really, some do exist, especially companies with a rule like "One week
of training every two years."
In my experience, companies that have some training offered to employees are either better places to work or at least tend to pay better.
Plus, by knowing the people that work for the company, you'll know a lot more going on. You'll know the technologies they use, the problems they have, and you'll know if the employees there like it or hate it. In short, you will know if you want the job or not.
2c) Found your own regional conference. Again, I've done this, it's not as hard as it sounds, but this one actually does take some work. If you check out my comments from around November of 2006, you'll see some the results of our after action review from our first year of GLSEC.
(Option 2D is to attend a free peer conference, such as WOPR, LAWST, or IWST, but I suspect again that is an entirely different post.)
3) By the end of step two, you are attending a conference, probably every year. The next step is to move up from a regional conference to a national one. A few ways to do that ...
3a) When you move to the new job, make training a part of the hiring negotiation - at least every-other year. Ask about the training budget. Be specific. Be firm. Don't jump to a company that has recently made commitments and then suddenly had a hiring freeze.
3b) Find a national conference that you can drive to and get accepted as a speaker (or volunteer if possible). Then your company only has to kick in the fee for the hotel room.
3c) Based on your ever-expanding network, find a third job and ... you get the picture.
3d) Start writing or blogging enough to boot-strap demand. Then ask the conference company to cover your travel expenses. (If you speak for two or more hours, they are much more likely to do this. Speak for a half day and you'll get some kind of support, anyway.)
To sum up:
If you make attending conferences a goal in the same way that some people make "increasing salary" a goal, you're pretty sure to get it. If you really want salary, attending conferences is a decent way to get it - you can build connections, reputation, and companies that send people to conferences tend to have more money to spend.
There are possible exceptions.
You could have a niche role small enough that you can't find local conferences. (data modeling or business intelligence, for example) You could live in a "one company town" in the deep Midwest or mountain area. Outside of the US, you could live in a large town with very little in the way of IT jobs, or you might have to bootstrap a development or testing community.
It's late. I'm starting to ramble. Anyway, that's the strategy.
Next time: How to generate ideas ...
Actually, it's pretty simple.
1) Get involved in a local user's group. Meet colleagues, discuss ideas, help other people solve their problems, give presentations and/or join the leadership team. If you don't have a local user's group, found one. (No, it is not that hard - I founded the Grand Rapid Perl Mongers in 1998, a user's group that is still around. How to do that is a different post.)
Sidebar:
The value in the user's group is networking, but I disagree with a lot of people about networking. Some think it is about collecting a large rolodex or making acquaintances to 'get' a job or contract. Well, that might work; there are specific techniques people use to jump from lead to lead.
Personally, I don't buy it. Why would anyone want to connect to a leach? To network effectively, you need to get to know other people at least well enough to know what they are interested in. Once you do that, you listen to the problems they have and see if you can help. Eventually, people in your network will look forward to calls from you because they know you will be offering to help them in some way - or at least have something interesting to discuss. Perhaps, some day, a sense of reciprocity kicks in, and they mention an opportunity for you. Perhaps not. The point is, now a lot of people know you and your reputation grows.
---> And you'll use that sidebar reputation in step two.
2) Put your local reputation to good use:
You could ...
2a) Look for a regional conference or a national conference in your area.
If you live in a big city like Chicago, Indianapolis, Denver, or Portland you are sure to find a regional conference staffed by volunteers. This conference is probably close enough that there will be no travel costs and no hotel costs. It will be short enough that you can miss a day or two - a max of three days - not a week. And you can get in free in two different
ways; you can either speak or volunteer to help run the conference.
For that matter, there are a lot of big national conferences that are in the same place every year, like the Twin Cities, Minnesota area, the Orlando Florida Area, the Boston Area, SanFranciso , Orange County California, and so on. Again, you can get in by either speaking or, in many cases, even the big conferences allow a limited number of volunteer slots. Also, the big conferences may be as long as a week, but you can usually sign up for "Just the conference days" or "Just the tutorial days" and only miss three or four days of work.
If you live in the United States or Canada and can't find a local conference, drop a comment on my blog and I will see what I can do.
2b) Eventually, someone in your user's group will know someone else who is hiring. And if you are an active member of the group, they will have some ability to evaluate you, and possibly recommend you. So here's the secret: Go to a company that regularly sends it's technology employees to training. Really, some do exist, especially companies with a rule like "One week
of training every two years."
In my experience, companies that have some training offered to employees are either better places to work or at least tend to pay better.
Plus, by knowing the people that work for the company, you'll know a lot more going on. You'll know the technologies they use, the problems they have, and you'll know if the employees there like it or hate it. In short, you will know if you want the job or not.
2c) Found your own regional conference. Again, I've done this, it's not as hard as it sounds, but this one actually does take some work. If you check out my comments from around November of 2006, you'll see some the results of our after action review from our first year of GLSEC.
(Option 2D is to attend a free peer conference, such as WOPR, LAWST, or IWST, but I suspect again that is an entirely different post.)
3) By the end of step two, you are attending a conference, probably every year. The next step is to move up from a regional conference to a national one. A few ways to do that ...
3a) When you move to the new job, make training a part of the hiring negotiation - at least every-other year. Ask about the training budget. Be specific. Be firm. Don't jump to a company that has recently made commitments and then suddenly had a hiring freeze.
3b) Find a national conference that you can drive to and get accepted as a speaker (or volunteer if possible). Then your company only has to kick in the fee for the hotel room.
3c) Based on your ever-expanding network, find a third job and ... you get the picture.
3d) Start writing or blogging enough to boot-strap demand. Then ask the conference company to cover your travel expenses. (If you speak for two or more hours, they are much more likely to do this. Speak for a half day and you'll get some kind of support, anyway.)
To sum up:
If you make attending conferences a goal in the same way that some people make "increasing salary" a goal, you're pretty sure to get it. If you really want salary, attending conferences is a decent way to get it - you can build connections, reputation, and companies that send people to conferences tend to have more money to spend.
There are possible exceptions.
You could have a niche role small enough that you can't find local conferences. (data modeling or business intelligence, for example) You could live in a "one company town" in the deep Midwest or mountain area. Outside of the US, you could live in a large town with very little in the way of IT jobs, or you might have to bootstrap a development or testing community.
It's late. I'm starting to ramble. Anyway, that's the strategy.
Next time: How to generate ideas ...
Monday, June 04, 2007
Tutorials and Training
In a response to my blog post on training, Mark wrote:
I would worry more about the thrashing effect of a developer testing course which did not focus on a specific developer tool set. Choosing a specific tool set allows the teacher to remove many variables from the discussion so they can rapidly teach concepts like "red, green, refactor" without spending time deciding if pyunit, nunit, junit, TestNG, or utplsql is the right choice for the user.
I agree, and here's what I'm thinking -
A one-day course on "What works in software testing: Or How To be Lazy Without Really Trying" (With Credit Mike Schwern, of course)
Before the course, attendees email a list of the core technologies they work on. Then, we customize the afternoon, perhaps splitting into small groups.
Essentially, the course is "Homebrew Test Automation"++ - as a workshop.
Now, the whole idea isn't fully baked, but developing ideas with people on the cutting edge is part of what I use this blog for. The risks in the format are medium-sized; people REALLY like stable, repeatable training and start to weird out when I customize training on the fly. Such custom training is also hard to get right and easy to get wrong.
Still, that's what I'm thinking about right now. What do you think?
I would worry more about the thrashing effect of a developer testing course which did not focus on a specific developer tool set. Choosing a specific tool set allows the teacher to remove many variables from the discussion so they can rapidly teach concepts like "red, green, refactor" without spending time deciding if pyunit, nunit, junit, TestNG, or utplsql is the right choice for the user.
I agree, and here's what I'm thinking -
A one-day course on "What works in software testing: Or How To be Lazy Without Really Trying" (With Credit Mike Schwern, of course)
Before the course, attendees email a list of the core technologies they work on. Then, we customize the afternoon, perhaps splitting into small groups.
Essentially, the course is "Homebrew Test Automation"++ - as a workshop.
Now, the whole idea isn't fully baked, but developing ideas with people on the cutting edge is part of what I use this blog for. The risks in the format are medium-sized; people REALLY like stable, repeatable training and start to weird out when I customize training on the fly. Such custom training is also hard to get right and easy to get wrong.
Still, that's what I'm thinking about right now. What do you think?
Lightning Talks Wrap-Up
Just a quick after-action review from STAREast --
Overall it was a great experience. Alan Page has his lightning talk up on-line in English Prose; Michael Bolton has his as a powerpoint (look for his May 27 Post), and I integrated mine into the post Conferences II.
One thing I tried this year that was different was outlawing power point; each speaker had to present using only words, markers and paper.
Of course, the audience would expect powerpoint, so for each speaker we had an intro slide on a black background with white letters - name, title, company, and logo. Then after that I had a completely black slide.
Switching to completely black messed with the projector; it thought there was no content. So I had to change the slides to very-very-very dark grey.
Overall, I think it was distracting. Next time, I will either allow powerpoint from the presenters, or have none at all. It was a nice experiment, but the middle road is often not the best one. :-)
Another thing I tried was to shorten then intro/conclusion, run the talks as fast as possible, and, time permitting, shim in a tenth talk. This gave the audience the maximum amount of content for the time.
Sadly, this means we missed a few things (like "Can we get a round of applause for all the speakers?") and I think the audience missed some closure.
So, as great as Michael Bolton's second speech was, I think that in the future I will stick with nine.
Oh, and I give away a noisemaker, which never seems to go well. I need to just go buy a gong.
(Some people who were at STAREast will reply "Matt, what are you talking about? The LT's were great!" And perhaps you are right. Still, I've heard a title for people who aren't self-critical and constantly trying to improve - and that title is 'Amateur' ...)
Overall it was a great experience. Alan Page has his lightning talk up on-line in English Prose; Michael Bolton has his as a powerpoint (look for his May 27 Post), and I integrated mine into the post Conferences II.
One thing I tried this year that was different was outlawing power point; each speaker had to present using only words, markers and paper.
Of course, the audience would expect powerpoint, so for each speaker we had an intro slide on a black background with white letters - name, title, company, and logo. Then after that I had a completely black slide.
Switching to completely black messed with the projector; it thought there was no content. So I had to change the slides to very-very-very dark grey.
Overall, I think it was distracting. Next time, I will either allow powerpoint from the presenters, or have none at all. It was a nice experiment, but the middle road is often not the best one. :-)
Another thing I tried was to shorten then intro/conclusion, run the talks as fast as possible, and, time permitting, shim in a tenth talk. This gave the audience the maximum amount of content for the time.
Sadly, this means we missed a few things (like "Can we get a round of applause for all the speakers?") and I think the audience missed some closure.
So, as great as Michael Bolton's second speech was, I think that in the future I will stick with nine.
Oh, and I give away a noisemaker, which never seems to go well. I need to just go buy a gong.
(Some people who were at STAREast will reply "Matt, what are you talking about? The LT's were great!" And perhaps you are right. Still, I've heard a title for people who aren't self-critical and constantly trying to improve - and that title is 'Amateur' ...)
Wednesday, May 02, 2007
Lightning Talk Mojo - I
Breathing readers of Creative Chaos know that I am facilitating Lightning TalksatSTAREast 2007 - astute ones realize that I am a genuine fan of the concept.
I would like to tell you why.
This year, I've been doing a good bit of back and forth with the lightning talk speakers - encouraging them to turn off powerpoint, and really talk to the audience.
One speaker wrote back that doing a whole five minute speech without powerpoint assistance would be hard.
And he's right.
But that's bad.
Powerpoint is a crutch.
Here's the deep, dark secret of presentations:
Outside of the basic, introductory, everything-I-say-is-new type of talk, in a typical presentation, your audience will leave with just a few nuggets. Sometimes, you only have one nugget, and spend the entire hour beating the audience over the head with it.
Still, most of the time, the audience is listening for insight. The more insights you can sprinkle into your talk, the better.
So, let's assume that a good nugget takes about five minutes to explain. That means it should be possible to do ten nuggets in a talk. Of course,different people need different things, so we'll assume that for any given audience member, only have of the "nuggets" will connect.
Now let's examine the typical 1-hour auto-content-generated slideware talk for a moment:
Start with time for ten nuggets
Intro - 10 minutes - Subtract two. Eight left.
Conclusion - 10 minute - Subtract two. Six left.
Q&A - 15 minutes - Subtract three. THREE NUGGETS LEFT.
Divide by two, because only half of the ideas will be relevant to any audience member.
That means for a one-hour talk, you get to make have about one-point-five actual insights that can change behavior.
That is a lot of sitting around, waiting for something to happen, and not much happening.
How can we do better?
The Intro/Body/Conclusion/QA style is, well, redundant. If you study Toastmasters, they openly admit this - the whole point is to tell 'em three times, so your single point comes across.
That might work when you are briefing the boss, but at a technical conference, why prove one point when you could prove ten? Even if half your stuff doesn't apply, and the audience hates half that does apply, heck - you still get to make two and a half points an hour. :-)
I see at least two problems with this:
First, learning to make a point succinctly in five minutes is hard.
Second, the very cognitive format of powerpoint, with it's bullets and lists, tends to turn your stuff into marketing-ware. Trying to make one point with powerpoint in one slide (or two) is, well ... hard.
My suggestions are -
1) Pschologists have discovered a method called "chunking" that people use to memorize extremely large pieces of material. Essentially, you take a big piece of data and split it into many small groups. For example, if you meet someone who has memorized PI to 1,000 digits, you will find that he probably hasn't memorized a thousand numbers at all. Instead, he has memorized a hundred-odd "chunks", where each chunk is five to ten numbers.
So is a one-hour talk a collection of ten "chunks"
2) Look into other communications options like handouts, discussion, or writing on an Easel. Read The Cognitive Value of PowerPoint by Tufte and The Gettysburg PowerPoint Presentation by Norvig.
3) If you really want to use powerpoint, consider the "one big slide per point" approach. That means reading, listening, and watching people who use this technique effectively - Tim Lister is a good one to follow.
4) Get really good at making a single point, making it well, and moving on. A good way to do that is to give lightning talks at conferences ...
Have I sold you on lightning talks yet?
If yes, your next question is probably "ok, so how do I get really good at chunking my talk?
More to come.
Post-Script: Paul Graham has an article on similar themes about writing essays - you can find it here. Even if you don't agree with the guy, you'll enjoy the read, I promise.)
I would like to tell you why.
This year, I've been doing a good bit of back and forth with the lightning talk speakers - encouraging them to turn off powerpoint, and really talk to the audience.
One speaker wrote back that doing a whole five minute speech without powerpoint assistance would be hard.
And he's right.
But that's bad.
Powerpoint is a crutch.
Here's the deep, dark secret of presentations:
Outside of the basic, introductory, everything-I-say-is-new type of talk, in a typical presentation, your audience will leave with just a few nuggets. Sometimes, you only have one nugget, and spend the entire hour beating the audience over the head with it.
Still, most of the time, the audience is listening for insight. The more insights you can sprinkle into your talk, the better.
So, let's assume that a good nugget takes about five minutes to explain. That means it should be possible to do ten nuggets in a talk. Of course,different people need different things, so we'll assume that for any given audience member, only have of the "nuggets" will connect.
Now let's examine the typical 1-hour auto-content-generated slideware talk for a moment:
Start with time for ten nuggets
Intro - 10 minutes - Subtract two. Eight left.
Conclusion - 10 minute - Subtract two. Six left.
Q&A - 15 minutes - Subtract three. THREE NUGGETS LEFT.
Divide by two, because only half of the ideas will be relevant to any audience member.
That means for a one-hour talk, you get to make have about one-point-five actual insights that can change behavior.
That is a lot of sitting around, waiting for something to happen, and not much happening.
How can we do better?
The Intro/Body/Conclusion/QA style is, well, redundant. If you study Toastmasters, they openly admit this - the whole point is to tell 'em three times, so your single point comes across.
That might work when you are briefing the boss, but at a technical conference, why prove one point when you could prove ten? Even if half your stuff doesn't apply, and the audience hates half that does apply, heck - you still get to make two and a half points an hour. :-)
I see at least two problems with this:
First, learning to make a point succinctly in five minutes is hard.
Second, the very cognitive format of powerpoint, with it's bullets and lists, tends to turn your stuff into marketing-ware. Trying to make one point with powerpoint in one slide (or two) is, well ... hard.
My suggestions are -
1) Pschologists have discovered a method called "chunking" that people use to memorize extremely large pieces of material. Essentially, you take a big piece of data and split it into many small groups. For example, if you meet someone who has memorized PI to 1,000 digits, you will find that he probably hasn't memorized a thousand numbers at all. Instead, he has memorized a hundred-odd "chunks", where each chunk is five to ten numbers.
So is a one-hour talk a collection of ten "chunks"
2) Look into other communications options like handouts, discussion, or writing on an Easel. Read The Cognitive Value of PowerPoint by Tufte and The Gettysburg PowerPoint Presentation by Norvig.
3) If you really want to use powerpoint, consider the "one big slide per point" approach. That means reading, listening, and watching people who use this technique effectively - Tim Lister is a good one to follow.
4) Get really good at making a single point, making it well, and moving on. A good way to do that is to give lightning talks at conferences ...
Have I sold you on lightning talks yet?
If yes, your next question is probably "ok, so how do I get really good at chunking my talk?
More to come.
Post-Script: Paul Graham has an article on similar themes about writing essays - you can find it here. Even if you don't agree with the guy, you'll enjoy the read, I promise.)
Wednesday, April 25, 2007
Upcoming Workshop
I will be running a small private workshop next month - about public speaking - for new speakers.
That's right; I am giving a talk on how to give a talk.
If you are interested in a pilot or peer review, shoot me an email.
That's right; I am giving a talk on how to give a talk.
If you are interested in a pilot or peer review, shoot me an email.
Indy Trip Report
Last month I made it out to Indianapolis for a meeting of the Indianapolis QA Association and a short course on software requirements. Sadly, I tried to make the event a working vacation, which meant I had not quite enough time to spend with technologists, yet also not enough time to really spend with my family.
A couple highlights -
1) The slides from my talk on process improvement are available online. If you open the document in powerpoint, you will see detailed (if not proof-read) lecture notes in the notes window.
2) I got the chance to meet some interesting people from Liberty Mutual, including David Christiansen. Apparently, David liked my talk enough to quote me; that's always a good sign. David also runs the blog site The Tech Darkside, which has some good material on it.
All told, it was a good trip. The requirements class was a bit too big for one facilitator (33 people), and this slowed down the general pace. In the future, I will either hold the line on attendance or bring in a second facilitator.
A couple highlights -
1) The slides from my talk on process improvement are available online. If you open the document in powerpoint, you will see detailed (if not proof-read) lecture notes in the notes window.
2) I got the chance to meet some interesting people from Liberty Mutual, including David Christiansen. Apparently, David liked my talk enough to quote me; that's always a good sign. David also runs the blog site The Tech Darkside, which has some good material on it.
All told, it was a good trip. The requirements class was a bit too big for one facilitator (33 people), and this slowed down the general pace. In the future, I will either hold the line on attendance or bring in a second facilitator.
Monday, April 09, 2007
Way Over Book-ed ...
I know, the past few months haven't provided the typical Creative Chaos output.
So, here's what I have been doing -
1) Evaluating Submissions for Lightning Talks at STAREast this year - which I hope to announce this week.
2) Preparing for a private workshop in Orlando, in May,
3) Working on a pre-publication book review for Addison-Wesley,
4) Trying to get around to doing the review of Brian Marick's Everyday Scripting with Ruby,
5) Lining up Keynote Speakers and Tutorial Speakers for GLSEC 2007. No, recruiting high-level speakers is not all glory; there is a lot of nagging and contracts involved. Though it is, mostly glory ...
6) Working on lining up sponsors for GLSEC 2007. This mostly consists of asking polietly, with the ocassional grovelling. I am sad to say, this one is not glory at all. And no, I don't make a dime on GLSEC, it, plus the local perl user's group, are my big volunteer work for the industry.
7) Trying to do any writing at all. I think the testing challenge of a few weeks back could be published, if only I would ever get off my duff.
8) www.xndev.com will lose it's web host next week. Find a new one.
9) In my free time, I need to get started on my 2008 speaking schedule
Then there's the kids, family, Church, knights of columbus, and the real work that lets me do this fun stuff. Oh, and something about colored eggs or a bunny or something.
It's been a whirl.
So, for this month, I have scaled back Creative Chaos, and, yes, this week I am scaling back my regular exercise routine to get some things knocked off that list.
Next on my to-do list: Learn to evaluate opportunities in light of what I can actually accomplish ...
Sigh.
One thing you can say about being overbooked: It ain't boring ...
So, here's what I have been doing -
1) Evaluating Submissions for Lightning Talks at STAREast this year - which I hope to announce this week.
2) Preparing for a private workshop in Orlando, in May,
3) Working on a pre-publication book review for Addison-Wesley,
4) Trying to get around to doing the review of Brian Marick's Everyday Scripting with Ruby,
5) Lining up Keynote Speakers and Tutorial Speakers for GLSEC 2007. No, recruiting high-level speakers is not all glory; there is a lot of nagging and contracts involved. Though it is, mostly glory ...
6) Working on lining up sponsors for GLSEC 2007. This mostly consists of asking polietly, with the ocassional grovelling. I am sad to say, this one is not glory at all. And no, I don't make a dime on GLSEC, it, plus the local perl user's group, are my big volunteer work for the industry.
7) Trying to do any writing at all. I think the testing challenge of a few weeks back could be published, if only I would ever get off my duff.
8) www.xndev.com will lose it's web host next week. Find a new one.
9) In my free time, I need to get started on my 2008 speaking schedule
Then there's the kids, family, Church, knights of columbus, and the real work that lets me do this fun stuff. Oh, and something about colored eggs or a bunny or something.
It's been a whirl.
So, for this month, I have scaled back Creative Chaos, and, yes, this week I am scaling back my regular exercise routine to get some things knocked off that list.
Next on my to-do list: Learn to evaluate opportunities in light of what I can actually accomplish ...
Sigh.
One thing you can say about being overbooked: It ain't boring ...
Wednesday, February 21, 2007
Conference Presentation Idea ...
Secrets of Enterprise Development
What can we learn about Project Scheduling from Mr. Scott? Security from Mr. Worf? Architecture from Data, Engineering from Geordi, Analysis from Spock, and Leadership from Kirk? Borrowing from human psycology and using Star Trek as a backdrop, Matt Heusser will cover the mythology of software development, and what happens when you involve real people, with all the faults and foibles they actually have.
No, seriously, this might make a decent talk. Gene Rodenberry, the creator of Star Trek, often admitted that the show was half social commentary. The other shows at the time, like GunSmoke and Bonanza, were historical. In those other shows, you couldn't show a female as a cowboy or an asian as a business owner - nor could you show the dark side of racism. But in Star Trek, to show racism, you could make the other race an alien, or use a racially diverse cast to show how essentially human and similar we all are when compared to the pandorian wampus-beast.
Also, I think the term "Enterprise Development" is vaguely lame. It usually means "Software Development in a big, dumb, slow company that is producing software a cost center, not an investment or profit center." So, in the talk, I could address some of the weaknesses of "enterprisy" development with humor, which is about the only way to do it.
The big problem is that this isn't a conference talk - it's a lightning talk. It's five minutes of real material, and then some serious fluffage. So I need real examples from Trek beyond Scotty and the Kobayashi Maru.
So, I have a few, but I don't want to spoil them. What are your ideas?
What can we learn about Project Scheduling from Mr. Scott? Security from Mr. Worf? Architecture from Data, Engineering from Geordi, Analysis from Spock, and Leadership from Kirk? Borrowing from human psycology and using Star Trek as a backdrop, Matt Heusser will cover the mythology of software development, and what happens when you involve real people, with all the faults and foibles they actually have.
No, seriously, this might make a decent talk. Gene Rodenberry, the creator of Star Trek, often admitted that the show was half social commentary. The other shows at the time, like GunSmoke and Bonanza, were historical. In those other shows, you couldn't show a female as a cowboy or an asian as a business owner - nor could you show the dark side of racism. But in Star Trek, to show racism, you could make the other race an alien, or use a racially diverse cast to show how essentially human and similar we all are when compared to the pandorian wampus-beast.
Also, I think the term "Enterprise Development" is vaguely lame. It usually means "Software Development in a big, dumb, slow company that is producing software a cost center, not an investment or profit center." So, in the talk, I could address some of the weaknesses of "enterprisy" development with humor, which is about the only way to do it.
The big problem is that this isn't a conference talk - it's a lightning talk. It's five minutes of real material, and then some serious fluffage. So I need real examples from Trek beyond Scotty and the Kobayashi Maru.
So, I have a few, but I don't want to spoil them. What are your ideas?
Monday, February 19, 2007
Teaching 'Agile' Testing
Elisabeth Hendrickson recently posted a request for feedback on teaching agile testing.
I liked the question so much that I wrote up a long reply; so long, in fact, that goes better as a blog post than a blog reply.
The tone is even more informal than a typical blog entry for me, but I hope you find it interesting. My goal was to get the ideas down, so I go pretty quickly. If you'd like to hear more detail ("What is the minefield problem in test automation", or "How can I automate a use case", or such) - just comment.
So, without futher ado ...
I am currently finishing up a couple of courses for software developers about testing. I suppose you could call it 'Agile'; I like the term "light-weight methods" or feedback driven or whatever.
I also struggled with how to cover the material. Several of the students (and some of the management) wanted me to dive right into a specific framework. "Teach blahUnit" came the request.
Whatever, dude. You can't automate what you can't do manually.
So yes, we started with equivalence classes, bounds, and traditional requirements-y techniques - stuff you could get from Dr Kaner's BBST course. I also covered scenario testing and use-case driven "acceptance" testing.
Then we did an exercise. I split the class into three groups - the first did entirely document-driven, requirements-based testing. They had to write scripts for the test cases before those were executed, and group one could only execute those tests.
The second group also did scripted, document-driven testing on the same app, but I gave them both the requirements and then demoed the UI. This way, the group could develop the scripted tests with the user interface in mind.
The third group had the requirements and the demo, but did exploratory testing.
After the exercise, I asked every team member to count how many bugs they found - down to root cause. I averaged this per team. I also asked the teams to evaluate how much fun they had - on a scale from 1 to 10, with 1 being "I'd rather have teeth pulled", 5 is "Well, at least I'm getting paid", and 10 is "I want to do this for a living"
Without exception (and I've done this twice now), the first group hated it and found few bugs, the second group found it merely distasteful and found more bugs, and the third group slightly enjoyed it and found the most bugs.
After that, I explain the mine field problem of test automation, the use case-driven view, the ripple effect and the value of test automation to increase confidence in the ripple. Finally, I cover high-volume test automation.
We try to figure out which of the three kinds of test automation make sense where, then explore those with the frameworks that make sense for that team.
Finally, we swing back around to try to form a comprehensive view of exploratory testing, acceptance testing, and test automation.
My take on it is that you can't automate what you can't do manually, and if you automate what you do crappily, you will get bad tests that are cheap to run – but expensive to write.
So I'd make it a two-day class, cover a valid testing worldview that is compatible with agile the first day, and then do all the 'agile' stuff (xUnit, continuous integration, TDD, fitness-y, and so on) on the second day.
I’m on the fence about interaction-based testing. Like a lot of other things (Agile, Lean, TDD) it’s easy to misunderstand, think you are doing it right, but actually waste a lot of time with little benefit while getting code bloat. Specifically, one of the original papers on interaction-based testing had an example that, I believe, sent people writing the wrong kind of tests. Then again, on certain systems, done right, it can increase quality, readability, and time to market. (Just like Agile, Lead, and TDD)
For database systems, I teach stubs (stub out data) not mocks. (fake out behavior)
But that's just me talkin'. In my old age, I find less and less interest in tools and more in skills. It sounds like your class covers agile skills more, so please, Elisabeth, tell us more.
I liked the question so much that I wrote up a long reply; so long, in fact, that goes better as a blog post than a blog reply.
The tone is even more informal than a typical blog entry for me, but I hope you find it interesting. My goal was to get the ideas down, so I go pretty quickly. If you'd like to hear more detail ("What is the minefield problem in test automation", or "How can I automate a use case", or such) - just comment.
So, without futher ado ...
I am currently finishing up a couple of courses for software developers about testing. I suppose you could call it 'Agile'; I like the term "light-weight methods" or feedback driven or whatever.
I also struggled with how to cover the material. Several of the students (and some of the management) wanted me to dive right into a specific framework. "Teach blahUnit" came the request.
Whatever, dude. You can't automate what you can't do manually.
So yes, we started with equivalence classes, bounds, and traditional requirements-y techniques - stuff you could get from Dr Kaner's BBST course. I also covered scenario testing and use-case driven "acceptance" testing.
Then we did an exercise. I split the class into three groups - the first did entirely document-driven, requirements-based testing. They had to write scripts for the test cases before those were executed, and group one could only execute those tests.
The second group also did scripted, document-driven testing on the same app, but I gave them both the requirements and then demoed the UI. This way, the group could develop the scripted tests with the user interface in mind.
The third group had the requirements and the demo, but did exploratory testing.
After the exercise, I asked every team member to count how many bugs they found - down to root cause. I averaged this per team. I also asked the teams to evaluate how much fun they had - on a scale from 1 to 10, with 1 being "I'd rather have teeth pulled", 5 is "Well, at least I'm getting paid", and 10 is "I want to do this for a living"
Without exception (and I've done this twice now), the first group hated it and found few bugs, the second group found it merely distasteful and found more bugs, and the third group slightly enjoyed it and found the most bugs.
After that, I explain the mine field problem of test automation, the use case-driven view, the ripple effect and the value of test automation to increase confidence in the ripple. Finally, I cover high-volume test automation.
We try to figure out which of the three kinds of test automation make sense where, then explore those with the frameworks that make sense for that team.
Finally, we swing back around to try to form a comprehensive view of exploratory testing, acceptance testing, and test automation.
My take on it is that you can't automate what you can't do manually, and if you automate what you do crappily, you will get bad tests that are cheap to run – but expensive to write.
So I'd make it a two-day class, cover a valid testing worldview that is compatible with agile the first day, and then do all the 'agile' stuff (xUnit, continuous integration, TDD, fitness-y, and so on) on the second day.
I’m on the fence about interaction-based testing. Like a lot of other things (Agile, Lean, TDD) it’s easy to misunderstand, think you are doing it right, but actually waste a lot of time with little benefit while getting code bloat. Specifically, one of the original papers on interaction-based testing had an example that, I believe, sent people writing the wrong kind of tests. Then again, on certain systems, done right, it can increase quality, readability, and time to market. (Just like Agile, Lead, and TDD)
For database systems, I teach stubs (stub out data) not mocks. (fake out behavior)
But that's just me talkin'. In my old age, I find less and less interest in tools and more in skills. It sounds like your class covers agile skills more, so please, Elisabeth, tell us more.
Monday, February 05, 2007
Solid presentation advice ...
Suggestions and Examples of What Not to Submit
1. Attendees are paying to take classes—they don’t want to hear a sales pitch, no matter how thickly veiled. Please do not submit classes that feature your product or describe problems that happen to be solved by your products.
Attendees and the conference organizers are equally skeptical of technical talks proposed by marketing people, Business Development Managers or CEOs—unless that person has the appropriate technical background and experience. Even the appearance of a sales pitch, such as when a talk is given by a marketer, will cause people to not attend that class.
2. Attendees don’t need to be taught why something is important (why security testing is important, why testing early in the SDLC is important, etc….). If they sign up for the class, they already know that. In your abstract, explain how the attendees will learn HOW to do something by taking your class.
3. Read the Course Catalog from the previous conference to learn how the classes are described. Try to match that, and have a colleague review your submission to make sure that your abstract makes sense. Experience has shown that an incoherent abstract is not a good sign for a coherent presentation.
- From the Software Test&Performance Call for Speakers
If you run a conference, especially a regional or non-profit one, you might want to slap something like this right onto your call for speakers. After running a regional software conference and participating in a few more, I've seen pretty much all of these problems. Heck, I've seen them in Lightning Talks.
Sometimes it can be very hard for a program chair to know who to select and who not to. The best thing we can do to help is to give them solid presentations, a strong outline, and no fluff.
1. Attendees are paying to take classes—they don’t want to hear a sales pitch, no matter how thickly veiled. Please do not submit classes that feature your product or describe problems that happen to be solved by your products.
Attendees and the conference organizers are equally skeptical of technical talks proposed by marketing people, Business Development Managers or CEOs—unless that person has the appropriate technical background and experience. Even the appearance of a sales pitch, such as when a talk is given by a marketer, will cause people to not attend that class.
2. Attendees don’t need to be taught why something is important (why security testing is important, why testing early in the SDLC is important, etc….). If they sign up for the class, they already know that. In your abstract, explain how the attendees will learn HOW to do something by taking your class.
3. Read the Course Catalog from the previous conference to learn how the classes are described. Try to match that, and have a colleague review your submission to make sure that your abstract makes sense. Experience has shown that an incoherent abstract is not a good sign for a coherent presentation.
- From the Software Test&Performance Call for Speakers
If you run a conference, especially a regional or non-profit one, you might want to slap something like this right onto your call for speakers. After running a regional software conference and participating in a few more, I've seen pretty much all of these problems. Heck, I've seen them in Lightning Talks.
Sometimes it can be very hard for a program chair to know who to select and who not to. The best thing we can do to help is to give them solid presentations, a strong outline, and no fluff.
Thursday, February 01, 2007
Blue Man Group - I
First, some background. I submit that there are currently two very big extremes in the world of software conferences: Death by Powerpoint and Open Spaces.
The Death By PowerPoint Conferences involve going to see eight speakers a day read a list of bullet points off of slides. Now and again you'll see a metric. The outline of nearly every single presentation is usually something like this:
Opening Joke (Optional)
Intro - Thesis
Body
- Point A (Support 1, 2)
- Point B (Support 1, 2)
- Point C (Support 1, 2)
Conclusion
A, B, C, therefore - Thesis
It turns out that this is a terrible way to convey information. First, it's redundant - you end up making your point three times. Second, it's lossy - PowerPoint bullets are inherently terse. Third, it's a waste of your time. You would be better off reading a three-page paper that described the idea, or just reading the slides. At least reading the slides would only take ten minutes, instead of an entire hour.
Ugh.
The other extreme, Open Spaces, is an emergent ideal. You have a poster with rooms and times, people write down what they are interested in, and you show up and discuss. In Open Spaces, everyone takes on some responsibility to interact. This is better in that people are actually talking about things they are interested in, but it has a few challenges. The lecture model is familiar and easy for many people; Open Spaces make them uncomfortable. And while open spaces may work as a form of communal-learning, they ain't great for instructor-based training.
What could we learn about presentations from Blue Man Group?
Just about everything.
First off, Blue Man Group is three guys dressed in black, with every inch of exposed skin covered in some weird blue coating. They don't talk, but instead use gestures to convey meaning - successfully. Of the three, one is the leader, one is the curious one, and the third is the "big jerk." Despite the fact that the look identical, ten minutes into the act you can tell them apart by expression and behavior.
Then there is audience involvement. Not interaction - involvement. While you wait for the show to start, a flashing LED sign tells you the VIPs who are present, and asks you to wish various people "Happy Birthday." The staff hands out bits of headband-sized recycled paper, asking you to turn them into some kind of jewelry. (I wrapped mine around my arm; most people wrapped them around the head.)
During the show, the blue men turned all kinds of things (mostly PVC pipes) into percussion instruments, sprayed paint onto drums, splashed it everywhere and created art, had a backup band that played music, had various sets and skits that included video, and managed to make a point or two about the environment.
Whew. I haven't even scratched the surface.
The Blue Men brought an audience member on-stage, did Improvisational Comedy with her, then brought a second volunteer up, had him put on a poncho, tied him upside down, threw paint on him, then threw him against a piece of canvas to make art.
And it was all in good fun.
Ok. So what we have here is a simple message (like protect the environment) covered in art, music, video, and comedy. There was a simple script that the blue men could deviate from in the name of humor. Most of the events were scripted, but they came off as improv - like when someone came in late and the blue men shined a theatre light on them. That probably happens in every second show, but it sure felt improvisational.
So what should software training be?
-> Not open spaces and not a lecture model. Something in the middle, that involves more senses than just the hearing. We need to give examples, provide exercises, and let the audience steer the work. More than being told how to gather requirements, our audience needs to experience and feel it for themselves. This feeling of having done it reinforces training in a way that no metrics ever could.
In my book, training should be fun, meaningful, and leave you with some idea of what to do on Monday. Blue Man Group is theatre, it is entertainment - but I think it gave a better combination of meaning and what to do than many software talks.
If a SW talk isn't fun and meaningful, no one is going to remember anything else about it.
This doesn't feel done, bit it's late. What do you think?
The Death By PowerPoint Conferences involve going to see eight speakers a day read a list of bullet points off of slides. Now and again you'll see a metric. The outline of nearly every single presentation is usually something like this:
Opening Joke (Optional)
Intro - Thesis
Body
- Point A (Support 1, 2)
- Point B (Support 1, 2)
- Point C (Support 1, 2)
Conclusion
A, B, C, therefore - Thesis
It turns out that this is a terrible way to convey information. First, it's redundant - you end up making your point three times. Second, it's lossy - PowerPoint bullets are inherently terse. Third, it's a waste of your time. You would be better off reading a three-page paper that described the idea, or just reading the slides. At least reading the slides would only take ten minutes, instead of an entire hour.
Ugh.
The other extreme, Open Spaces, is an emergent ideal. You have a poster with rooms and times, people write down what they are interested in, and you show up and discuss. In Open Spaces, everyone takes on some responsibility to interact. This is better in that people are actually talking about things they are interested in, but it has a few challenges. The lecture model is familiar and easy for many people; Open Spaces make them uncomfortable. And while open spaces may work as a form of communal-learning, they ain't great for instructor-based training.
What could we learn about presentations from Blue Man Group?
Just about everything.
First off, Blue Man Group is three guys dressed in black, with every inch of exposed skin covered in some weird blue coating. They don't talk, but instead use gestures to convey meaning - successfully. Of the three, one is the leader, one is the curious one, and the third is the "big jerk." Despite the fact that the look identical, ten minutes into the act you can tell them apart by expression and behavior.
Then there is audience involvement. Not interaction - involvement. While you wait for the show to start, a flashing LED sign tells you the VIPs who are present, and asks you to wish various people "Happy Birthday." The staff hands out bits of headband-sized recycled paper, asking you to turn them into some kind of jewelry. (I wrapped mine around my arm; most people wrapped them around the head.)
During the show, the blue men turned all kinds of things (mostly PVC pipes) into percussion instruments, sprayed paint onto drums, splashed it everywhere and created art, had a backup band that played music, had various sets and skits that included video, and managed to make a point or two about the environment.
Whew. I haven't even scratched the surface.
The Blue Men brought an audience member on-stage, did Improvisational Comedy with her, then brought a second volunteer up, had him put on a poncho, tied him upside down, threw paint on him, then threw him against a piece of canvas to make art.
And it was all in good fun.
Ok. So what we have here is a simple message (like protect the environment) covered in art, music, video, and comedy. There was a simple script that the blue men could deviate from in the name of humor. Most of the events were scripted, but they came off as improv - like when someone came in late and the blue men shined a theatre light on them. That probably happens in every second show, but it sure felt improvisational.
So what should software training be?
-> Not open spaces and not a lecture model. Something in the middle, that involves more senses than just the hearing. We need to give examples, provide exercises, and let the audience steer the work. More than being told how to gather requirements, our audience needs to experience and feel it for themselves. This feeling of having done it reinforces training in a way that no metrics ever could.
In my book, training should be fun, meaningful, and leave you with some idea of what to do on Monday. Blue Man Group is theatre, it is entertainment - but I think it gave a better combination of meaning and what to do than many software talks.
If a SW talk isn't fun and meaningful, no one is going to remember anything else about it.
This doesn't feel done, bit it's late. What do you think?
Sunday, November 26, 2006
Presentations - III
For some time I've been trying to put together a post about the Blue Man Group - the seven-city theatre production that is, well ... unique. I recently saw Blue Man in Chicago, and it is an amazing combination of theatre, art, audience interaction, and improvisational comedy that creates a shared experience.
And yes, I know that's a lame explanation. I still haven't told you what the Blue Man Group does, or, the obvious reason to post - how that should or could affect the way we do presentations on software development.
Here's the first obvious part - Blue Man combines watching with doing - or at least, they create the illusion of it. It makes the entire experience more memorable, and, as I see it, a big part of the problem with the "drive by training" we do in software today is that it is entirely disconnected from what we do on Monday. Disconnected from who we are. That might be a good way to make money, but it's a lousy way to help an industry improve.
So, here's the second thing - Blue Man Group is going to be on SCRUBS on Thursday, November 30th. So before I bother to try to explain what they do, check out the TV show. If the TV show doesn't reflect the group, we'll there are a few blue man links available on video.
Also, I think the post on the requirements problem is pretty good, so if you haven't read it, please, scroll down ...
And yes, I know that's a lame explanation. I still haven't told you what the Blue Man Group does, or, the obvious reason to post - how that should or could affect the way we do presentations on software development.
Here's the first obvious part - Blue Man combines watching with doing - or at least, they create the illusion of it. It makes the entire experience more memorable, and, as I see it, a big part of the problem with the "drive by training" we do in software today is that it is entirely disconnected from what we do on Monday. Disconnected from who we are. That might be a good way to make money, but it's a lousy way to help an industry improve.
So, here's the second thing - Blue Man Group is going to be on SCRUBS on Thursday, November 30th. So before I bother to try to explain what they do, check out the TV show. If the TV show doesn't reflect the group, we'll there are a few blue man links available on video.
Also, I think the post on the requirements problem is pretty good, so if you haven't read it, please, scroll down ...
Thursday, November 16, 2006
GLSEC 2006 Presentations Online
The presentations from the 2006 Great Lakes Software Excellence Conference are now online -
http://www.glsec.org/pages/Presentations_2006. There is also Audio for Carl Erickson's keynote and most of Tim Lister's Keynote.
Both keynotes were good; Lister's audio starts off with the slide with the bull on it.
http://www.glsec.org/pages/Presentations_2006. There is also Audio for Carl Erickson's keynote and most of Tim Lister's Keynote.
Both keynotes were good; Lister's audio starts off with the slide with the bull on it.
Thursday, November 02, 2006
GLSEC Retrospective II
The gang's all here but we don't have the overall conference evals.
Agenda
A) Attendance Update
B) Financial Update
C) Sponsors
D) Go Around the table
E) Discuss Evaluation Results
Details:
A) We had 80 people the 1st day (tutorial day) and 140 the second. Those numbers include about 17 speakers on the second day, a nine sponor representatives on the second day, eight volunteers, and six representatives from calvin college on both days. (So pay customers were around 70% of the attendees, more or less)
B) We did end up with a little bit of money in the bank, but this is clearly a non-profit venture. The only reason we made it work was because volunteers were unpaid. Still, now we have a small cushion for next year.
We had a 50% refund advertised on the website; we need to make it clear that the refund ends 72 hours before the conference begins.
A process for capturing the waiting list would probably have been helpful. Also, one of the tutorials was very specific about how the tables should be organized and this artificially decreased the number of attendees; we sold out without knowing it. We got lucky because a few people cancelled at the last minute and that talk wasn't very popular with the Calvin staff.
At one point we were 5K in the red. This was scary, and we made a number of compromises (cheap food, cheap snacks, small conference brochure) to minimize risk. It's good to have a "big brother" so you don't have to make such compromises. We'll have that next year.
C) It might to helpful next year to provide a packet for sponsors that give them some insight into how to sell - have a raffle, make it clear that a list is not part of the deal, help them to evaluate if sponsoring is good for you, what you can get out of it, and so on. We could try to do more for our sponsors next year, including pushing sponsoring specific _events_, like lunch or a speaker.
D) It was nice to have a small space; this made the number of sponsors feel more. Then again, physically 'case the joint' and plan the sponsor space. To get to the food, people should have to walk past the spsonsors.
It's nice to have mints at the tables and water at the tables when possible.
We need a role of 'tutorial tender', much like the track chairs do the track days. (The speaker coordinator) Find out if tutorial speakers would like to be introduced.
Schedule Volunteer dinner early - Schedule meetings further in advance
More formally define committee vs. volunteer
Consider recognizing implicit sponsors (Companies that let employees do GLSEC work during company time)
Consider giving tickets to XPWM sponsors next year
Use the survey feature in registration software to capture all attendees, emails, and company names
Order books by authors sooner (Try harder to make the book signing work)
Luck Helps
Give Aways are fun - Encourage Sponsors to do more - Encourage Publishers
We need to firm up how we deal with sponsors who want to add more people beyond the one freebie attendee (This should be in our packet)
We need to be very about the expectations for attendance from partners
Laptops for tutorials - If laptops are required, we need to make the rediculously clear. Use follow-up features in registration software if possible, or, better yet, have the tutorial liason person do it.
When picking a date, try to coordinate with other conferences. I think fall is a pretty good niche for regional conferences. In theory we compete with PNSQC but the overlap between our conferences are minor because they are so local.
People have lives. So if we want to have evening events, they need to be advertised on the website months in advance.
Overall, we think middle of the week is better than the end. Easier to book, cheaper for travel, you can stay in town for the weekend if you want.
Make sure you can print nametags on-the-fly, just in case of typos and late registration.
More tangible, non-monetary rewards for out-of-town speakers and volenteers. Take people to a hockey game?
We like a small conference, high quality. That probably means we'll have to get some high-quality speakers either increase rates (slightly) or get more sponsor support.
Lock in keynotes and tutorials early. In general, the team should determine who they want to invite for keynotes and tutorials vs. a call for papers.
Suggest experience reports in the call for papers.
Give guidance to speakers about how to fit into 45 minutes, or limit talks to 30 minutes and push them hard. Get serious about giving presentors advice on how to give good talks.
Get serious about the peer review process - ask for an outline of what the person will do.
Try harder to get slides up on the website by 8:00AM the day after the conference.
The biggest take-home from one of our volunteers was Tim Lister's Risk Management talk. Consider bringing him back to do his Risk Management Tutorial next year.
The hickory room felt small.
E) We didn't get to this. More later ...
Agenda
A) Attendance Update
B) Financial Update
C) Sponsors
D) Go Around the table
E) Discuss Evaluation Results
Details:
A) We had 80 people the 1st day (tutorial day) and 140 the second. Those numbers include about 17 speakers on the second day, a nine sponor representatives on the second day, eight volunteers, and six representatives from calvin college on both days. (So pay customers were around 70% of the attendees, more or less)
B) We did end up with a little bit of money in the bank, but this is clearly a non-profit venture. The only reason we made it work was because volunteers were unpaid. Still, now we have a small cushion for next year.
We had a 50% refund advertised on the website; we need to make it clear that the refund ends 72 hours before the conference begins.
A process for capturing the waiting list would probably have been helpful. Also, one of the tutorials was very specific about how the tables should be organized and this artificially decreased the number of attendees; we sold out without knowing it. We got lucky because a few people cancelled at the last minute and that talk wasn't very popular with the Calvin staff.
At one point we were 5K in the red. This was scary, and we made a number of compromises (cheap food, cheap snacks, small conference brochure) to minimize risk. It's good to have a "big brother" so you don't have to make such compromises. We'll have that next year.
C) It might to helpful next year to provide a packet for sponsors that give them some insight into how to sell - have a raffle, make it clear that a list is not part of the deal, help them to evaluate if sponsoring is good for you, what you can get out of it, and so on. We could try to do more for our sponsors next year, including pushing sponsoring specific _events_, like lunch or a speaker.
D) It was nice to have a small space; this made the number of sponsors feel more. Then again, physically 'case the joint' and plan the sponsor space. To get to the food, people should have to walk past the spsonsors.
It's nice to have mints at the tables and water at the tables when possible.
We need a role of 'tutorial tender', much like the track chairs do the track days. (The speaker coordinator) Find out if tutorial speakers would like to be introduced.
Schedule Volunteer dinner early - Schedule meetings further in advance
More formally define committee vs. volunteer
Consider recognizing implicit sponsors (Companies that let employees do GLSEC work during company time)
Consider giving tickets to XPWM sponsors next year
Use the survey feature in registration software to capture all attendees, emails, and company names
Order books by authors sooner (Try harder to make the book signing work)
Luck Helps
Give Aways are fun - Encourage Sponsors to do more - Encourage Publishers
We need to firm up how we deal with sponsors who want to add more people beyond the one freebie attendee (This should be in our packet)
We need to be very about the expectations for attendance from partners
Laptops for tutorials - If laptops are required, we need to make the rediculously clear. Use follow-up features in registration software if possible, or, better yet, have the tutorial liason person do it.
When picking a date, try to coordinate with other conferences. I think fall is a pretty good niche for regional conferences. In theory we compete with PNSQC but the overlap between our conferences are minor because they are so local.
People have lives. So if we want to have evening events, they need to be advertised on the website months in advance.
Overall, we think middle of the week is better than the end. Easier to book, cheaper for travel, you can stay in town for the weekend if you want.
Make sure you can print nametags on-the-fly, just in case of typos and late registration.
More tangible, non-monetary rewards for out-of-town speakers and volenteers. Take people to a hockey game?
We like a small conference, high quality. That probably means we'll have to get some high-quality speakers either increase rates (slightly) or get more sponsor support.
Lock in keynotes and tutorials early. In general, the team should determine who they want to invite for keynotes and tutorials vs. a call for papers.
Suggest experience reports in the call for papers.
Give guidance to speakers about how to fit into 45 minutes, or limit talks to 30 minutes and push them hard. Get serious about giving presentors advice on how to give good talks.
Get serious about the peer review process - ask for an outline of what the person will do.
Try harder to get slides up on the website by 8:00AM the day after the conference.
The biggest take-home from one of our volunteers was Tim Lister's Risk Management talk. Consider bringing him back to do his Risk Management Tutorial next year.
The hickory room felt small.
E) We didn't get to this. More later ...
GLSEC - Retrospective I
We just finished ran GLSEC, the Great Lakes Software Excellence Conference, last week in Grand Rapids. This morning we meet for the debrief, retrospective, lessons learned thing. It should be fun. I intend to take notes; if everyone agrees, I'll post them here on Creative Chaos.
Wednesday, November 01, 2006
2007 - Potential Tutorials
I also have a ideas that could turn into half-to-multi day tutorials. Again, I'd be interested in any feedback. Yes, I know the how to break software tutorial needs work. It's goofy. Mostly, it's just the start of the germ seed of an idea, but I think it has potential. I am looking for feedback ...
Test Driven Development: Introduced
A 1-to-1.5 day tutorial and workshop
1 hour – Introduction to loops, variables, and subroutines
(Optional, over lunch?)
½ Day – Introduction to perl with exercises
½ Day - Introduction to TDD
½ Day – Hands-on TDD
Take-Away: Learning Perl (Wall)
‘Agile’ Testing: Demystified
Alt Title: Introduction to Agile Testing
Alt Title 2: Introduction to Agile Testing Practices
A ½ to 1 day tutorial/workshop
Abstract:
The Agile Manifesto has swept the software development community, but what does it mean for software testing? No, really, how can we apply it? In this tutorial Matt Heusser will explain the software agile manifesto in three ways: With words, examples, and participative effort, then step back and discuss and do some agile software testing.
This workshop intends to answer the following questions:
What the heck is this agile thing?
Would this agile thing be helpful to my organization?
If yes, how much?
How can I influence my organization to be more agile?
After all, “I am just a”
How does the tester role fit into this agile thing?
What are the limits of developer-facing testing, and how is black box testing different? How and should black-box testing “compete” against developer-facing testing?
What should I do on Monday?
Software Leadership
A 1-to-2 day tutorial
½ day – Software Management
½ day – Hiring the best
½ day – Solving the requirements problem
½ day – Software Scheduling Secrets
Take-Away: Behind Closed Doors: Secrets of Great Management
Test Case Design
A 1 day tutorial
Take-Away: A practitioner’s guide to software test design (Copeland)
Black Box Software Testing
A 1-2 day course that discusses challenges and approaches to software testing
What is software testing?
-> Applied Critical thinking
-> Can happen throughout the lifecycle
-> White Vs. Black-Box
Challenges of Software Testing
Risk-based testing approaches and Rapid Testing Approaches
Requirements-based testing approaches
Test Estimation
Bug Advocacy
Domain Testing
Regression Testing
Traceability
Test Automation
Test-Driven Development
Automated System Tests
Automated Acceptance Tests
Continuous Integration
How To Break Software: A Classic Approach
A 1-2 day course that introduces critical and creative thinking
Syllabus:
Introduction
- Career Paths
Exercise #1
- Test Cases for a salt shaker
A history of innovation
- Da Vinci, Gauss, Netwon, Asimov, Fenyman, Weinberg, Van Neuman, Turing, Goedel, Escher
Logic and Rational Thought
- Truth Tables, predicate logic, logical fallacy
Discrete Mathematics
- Venn
The philosophers
- Aristotle, Augustine, Aquinas, Ayn Rand, …
The philosophies
- Classical, Baroque, Enlightenment, Romance, Modern, Post-Modern
- Relativism, Epistemology
Exercise: Define where CMM, Waterfall, XP, RUP, fall on the continuum
- Plato’s Cave
Exercise: Find examples in the world of software testing
Number Theory
- Deduction Vs Induction
- Classic Proofs (Limits Problems, Pattern Recognition, Fibonacci)
Physics?
- Relationship of Acceleration to Velocity to Distance
- Newton’s Proof of Integration
Group Thinking
- Group Problem Solving
Modeling
- Exercise
The world system
- 90% of everything
- Zen&The Art of MM? (Drucker, Deming, Juran)
Exercise #2
- Applied thinking about the world system
Exercise #3
- Test Cases for a stapler
Test Driven Development: Introduced
A 1-to-1.5 day tutorial and workshop
1 hour – Introduction to loops, variables, and subroutines
(Optional, over lunch?)
½ Day – Introduction to perl with exercises
½ Day - Introduction to TDD
½ Day – Hands-on TDD
Take-Away: Learning Perl (Wall)
‘Agile’ Testing: Demystified
Alt Title: Introduction to Agile Testing
Alt Title 2: Introduction to Agile Testing Practices
A ½ to 1 day tutorial/workshop
Abstract:
The Agile Manifesto has swept the software development community, but what does it mean for software testing? No, really, how can we apply it? In this tutorial Matt Heusser will explain the software agile manifesto in three ways: With words, examples, and participative effort, then step back and discuss and do some agile software testing.
This workshop intends to answer the following questions:
What the heck is this agile thing?
Would this agile thing be helpful to my organization?
If yes, how much?
How can I influence my organization to be more agile?
After all, “I am just a
How does the tester role fit into this agile thing?
What are the limits of developer-facing testing, and how is black box testing different? How and should black-box testing “compete” against developer-facing testing?
What should I do on Monday?
Software Leadership
A 1-to-2 day tutorial
½ day – Software Management
½ day – Hiring the best
½ day – Solving the requirements problem
½ day – Software Scheduling Secrets
Take-Away: Behind Closed Doors: Secrets of Great Management
Test Case Design
A 1 day tutorial
Take-Away: A practitioner’s guide to software test design (Copeland)
Black Box Software Testing
A 1-2 day course that discusses challenges and approaches to software testing
What is software testing?
-> Applied Critical thinking
-> Can happen throughout the lifecycle
-> White Vs. Black-Box
Challenges of Software Testing
Risk-based testing approaches and Rapid Testing Approaches
Requirements-based testing approaches
Test Estimation
Bug Advocacy
Domain Testing
Regression Testing
Traceability
Test Automation
Test-Driven Development
Automated System Tests
Automated Acceptance Tests
Continuous Integration
How To Break Software: A Classic Approach
A 1-2 day course that introduces critical and creative thinking
Syllabus:
Introduction
- Career Paths
Exercise #1
- Test Cases for a salt shaker
A history of innovation
- Da Vinci, Gauss, Netwon, Asimov, Fenyman, Weinberg, Van Neuman, Turing, Goedel, Escher
Logic and Rational Thought
- Truth Tables, predicate logic, logical fallacy
Discrete Mathematics
- Venn
The philosophers
- Aristotle, Augustine, Aquinas, Ayn Rand, …
The philosophies
- Classical, Baroque, Enlightenment, Romance, Modern, Post-Modern
- Relativism, Epistemology
Exercise: Define where CMM, Waterfall, XP, RUP, fall on the continuum
- Plato’s Cave
Exercise: Find examples in the world of software testing
Number Theory
- Deduction Vs Induction
- Classic Proofs (Limits Problems, Pattern Recognition, Fibonacci)
Physics?
- Relationship of Acceleration to Velocity to Distance
- Newton’s Proof of Integration
Group Thinking
- Group Problem Solving
Modeling
- Exercise
The world system
- 90% of everything
- Zen&The Art of MM? (Drucker, Deming, Juran)
Exercise #2
- Applied thinking about the world system
Exercise #3
- Test Cases for a stapler
2007 Idea list
Every now and again I come up with a list of ideas that I am excited about, that are potential ideas for an article or talk. While I have no gift for the witty abstract, I do have a bunch of ideas that I would like to develop. If you would like to hear any of these (or think any of these stink), please drop a comment or email. Then check the blog; I will tell you if anything develops.
Economics for Software Testers
Alt Title: “The State of the Yard-Stick”
Alt Title II: “My next thirty years”
Falling into software testing is easy. The next question “where do I go next?” is a little bit harder. In this fast-paced talk, Matt Heusser covers three hundred years of economic development - from Adam Smith to offshore testing. Including economic models and real data, Matt will use existing trends to discuss where software testing could be heading, and how to profit from it.
The one-eyed man in the land of the blind:
Negotiation skills for software testers
Like Santa Clause and the Easter Bunny, the “Software Tester who knows how to negotiate” may seem like a fairy tale. The sad reality is that negotiation is everywhere, from scope to schedule to salary, yet few software testers practice this art … or even understand it. In this talk, Matt Heusser discusses who a negotiation is, introduces goals and strategy in negotiation, then goes on to cover tactics and skills. Finally, Matt provides opportunities and examples for participants to practice the skills in an environment without career-limiting consequences.
‘Agile’ Testing: Demystified
Alt Title: Introduction to Agile Testing
Alt Title 2: Introduction to Agile Testing Practices
A 1 to 2 hour presentation
This talk intends to answer the following questions:
What the heck is this agile thing?
Would this agile thing be helpful to my organization?
If yes, how much?
How can I influence my organization to be more agile?
After all, “I am just a”
How does the tester role fit into this agile thing?
What should I do on Monday?
Individuals and Interactions
… over processes and tools, reads the agile manifesto. Yet XP, Scrum, Crystal, ANT, Cruise Control – typical things to talk about in a discussion of agile practices – are all processes and tools! It turns out that focusing on individuals and interactions can often be hard to do and harder to define. Matt Heusser suggests the focusing on process at the expense of people creates opportunity cost, which could mean that real, working features are cut or late because of the wrong focus. He goes on to provides specific examples of how to shift your focus, practical exercises to help you stay there, and draws a picture of a few alternate ways that an organization might embrace individuals and interactions without giving up accountability.
A few of my favorite things:
30 Years of the best innovations in software engineering
One of the main causes of struggle in the technology industry is its perpetual youth - one generation is burning out while a new one is just starting. This means that each new group needs to learn the mistakes of the past, most often by doing them! In this brief tutorial Matt Heusser covers the landscape of thirty years of professional software engineering – where we came from, what we’ve learned, and how we can apply it. Matt suggests that each team needs to customize its development processes with an eye on the past, in a way that is, in his words, “Often right, occasionally wrong, but never boring.”
My paints and brush:
A testing artisan’s toolkit
Many software testers expect the employer to provide the paints and brushes for our artistic work. When the result is of limited quality, we complain about the lack time; not the paint-by-number set we were handed. Matt Heusser suggests that testing craftspeople need to take our tools seriously – to the point of owning tools that we personally carry from job to job. In this talk he covers a few of his favorites, including electronics, simple supplies, and software; many of it free, and all of it combined cheaper than a typical conference registration. Finally, Matt covers a few of the consequences of viewing ourselves as independent craftspeople with our own tool set, and makes some recommendations for Monday.
Presentation Zen
Zen (zn) n. (Dictionary.Com)
A school of Mahayana Buddhism that asserts that enlightenment can be attained through meditation, self-contemplation, and intuition rather than through faith and devotion …
Giving talks is hard. Giving talks can be scary. This presentation won’t make you a master of ceremonies or a professional comedian, but it might just help you increase you effectiveness as a speaker and build a little confidence along the way.
Context-Driven Software Engineering
Matt Heusser suggests that focusing on individual and interactions over processes and tools means just that. In this talk, he will discuss techniques to build skills and flex the process in the moment; to determine the best thing to do right now instead of consulting a manual. Matt will discuss the concept of Context-Driven Software Testing and introduce it’s twin in development – Context-Driven SE.
Keeping your gumption
The true variance in software development isn’t the hourly rate; it’s the amount of work that you can get done within that hour. Inspired and based on Zen and the Art of Motorcycle Maintenance, this talk discusses real, practical techniques to keep going despite adversity – and how to avoid that adversity in the first place.
Effective Bug Reporting
If you’re sick and tired of “It works on my machine”, “Unable to reproduce”, “Referred back to the testing group for research” and “This is not a bug”, you’ll want to attend this session. Matt Heusser discusses how to write bug reports that get noticed, communicate better with developers and managers, and improve your written communication skills – all at the same time. Along the way he’ll uncover a few reporting tips, tricks, and tools you can start using tomorrow.
Why Agile Principles Work
Agile principles aren’t “magic” and can’t create something from nothing. In this talk Matthew Heusser, a classically-trained mathematician, will weave together examples from physics, operations research, control theory, general business, math and software to help move the “why” of agile development away from alchemy and toward science and logical thought.
[Indirectly inspired by my talk “Magic Pixie Dust” which was a keynote at the Indiana QA Conference in 2005.]
Lightning Talks
Lightning Talks are fifteen five-minute talks in a ninety-minute time period. Come here a series of ideas all in a row - without the bluster, opening-joke, intro/body/conclusion, or Q&A session that doesn't really answer your questions. With Lightning Talks, the speakers have just enough time to make one point, make it well, and get off the stage. Leave with a half dozen new ideas to implement on Monday ... and if a speaker is bad, don't worry, he'll be off stage quickly.
Rethinking Process Improvement
Weaving together examples from general business, operations research, control theory and systems thinking, Matt Heusser suggests two areas of innovation: Process and Product. According to Heusser, companies can choose which, and how much, of these two to focus on, and he provides success and failure examples of both. Finally, Matt provides a new way to think about process improvement, grounded in the context of your company, its products and competitive environment.
Economics for Software Testers
Alt Title: “The State of the Yard-Stick”
Alt Title II: “My next thirty years”
Falling into software testing is easy. The next question “where do I go next?” is a little bit harder. In this fast-paced talk, Matt Heusser covers three hundred years of economic development - from Adam Smith to offshore testing. Including economic models and real data, Matt will use existing trends to discuss where software testing could be heading, and how to profit from it.
The one-eyed man in the land of the blind:
Negotiation skills for software testers
Like Santa Clause and the Easter Bunny, the “Software Tester who knows how to negotiate” may seem like a fairy tale. The sad reality is that negotiation is everywhere, from scope to schedule to salary, yet few software testers practice this art … or even understand it. In this talk, Matt Heusser discusses who a negotiation is, introduces goals and strategy in negotiation, then goes on to cover tactics and skills. Finally, Matt provides opportunities and examples for participants to practice the skills in an environment without career-limiting consequences.
‘Agile’ Testing: Demystified
Alt Title: Introduction to Agile Testing
Alt Title 2: Introduction to Agile Testing Practices
A 1 to 2 hour presentation
This talk intends to answer the following questions:
What the heck is this agile thing?
Would this agile thing be helpful to my organization?
If yes, how much?
How can I influence my organization to be more agile?
After all, “I am just a
How does the tester role fit into this agile thing?
What should I do on Monday?
Individuals and Interactions
… over processes and tools, reads the agile manifesto. Yet XP, Scrum, Crystal, ANT, Cruise Control – typical things to talk about in a discussion of agile practices – are all processes and tools! It turns out that focusing on individuals and interactions can often be hard to do and harder to define. Matt Heusser suggests the focusing on process at the expense of people creates opportunity cost, which could mean that real, working features are cut or late because of the wrong focus. He goes on to provides specific examples of how to shift your focus, practical exercises to help you stay there, and draws a picture of a few alternate ways that an organization might embrace individuals and interactions without giving up accountability.
A few of my favorite things:
30 Years of the best innovations in software engineering
One of the main causes of struggle in the technology industry is its perpetual youth - one generation is burning out while a new one is just starting. This means that each new group needs to learn the mistakes of the past, most often by doing them! In this brief tutorial Matt Heusser covers the landscape of thirty years of professional software engineering – where we came from, what we’ve learned, and how we can apply it. Matt suggests that each team needs to customize its development processes with an eye on the past, in a way that is, in his words, “Often right, occasionally wrong, but never boring.”
My paints and brush:
A testing artisan’s toolkit
Many software testers expect the employer to provide the paints and brushes for our artistic work. When the result is of limited quality, we complain about the lack time; not the paint-by-number set we were handed. Matt Heusser suggests that testing craftspeople need to take our tools seriously – to the point of owning tools that we personally carry from job to job. In this talk he covers a few of his favorites, including electronics, simple supplies, and software; many of it free, and all of it combined cheaper than a typical conference registration. Finally, Matt covers a few of the consequences of viewing ourselves as independent craftspeople with our own tool set, and makes some recommendations for Monday.
Presentation Zen
Zen (zn) n. (Dictionary.Com)
A school of Mahayana Buddhism that asserts that enlightenment can be attained through meditation, self-contemplation, and intuition rather than through faith and devotion …
Giving talks is hard. Giving talks can be scary. This presentation won’t make you a master of ceremonies or a professional comedian, but it might just help you increase you effectiveness as a speaker and build a little confidence along the way.
Context-Driven Software Engineering
Matt Heusser suggests that focusing on individual and interactions over processes and tools means just that. In this talk, he will discuss techniques to build skills and flex the process in the moment; to determine the best thing to do right now instead of consulting a manual. Matt will discuss the concept of Context-Driven Software Testing and introduce it’s twin in development – Context-Driven SE.
Keeping your gumption
The true variance in software development isn’t the hourly rate; it’s the amount of work that you can get done within that hour. Inspired and based on Zen and the Art of Motorcycle Maintenance, this talk discusses real, practical techniques to keep going despite adversity – and how to avoid that adversity in the first place.
Effective Bug Reporting
If you’re sick and tired of “It works on my machine”, “Unable to reproduce”, “Referred back to the testing group for research” and “This is not a bug”, you’ll want to attend this session. Matt Heusser discusses how to write bug reports that get noticed, communicate better with developers and managers, and improve your written communication skills – all at the same time. Along the way he’ll uncover a few reporting tips, tricks, and tools you can start using tomorrow.
Why Agile Principles Work
Agile principles aren’t “magic” and can’t create something from nothing. In this talk Matthew Heusser, a classically-trained mathematician, will weave together examples from physics, operations research, control theory, general business, math and software to help move the “why” of agile development away from alchemy and toward science and logical thought.
[Indirectly inspired by my talk “Magic Pixie Dust” which was a keynote at the Indiana QA Conference in 2005.]
Lightning Talks
Lightning Talks are fifteen five-minute talks in a ninety-minute time period. Come here a series of ideas all in a row - without the bluster, opening-joke, intro/body/conclusion, or Q&A session that doesn't really answer your questions. With Lightning Talks, the speakers have just enough time to make one point, make it well, and get off the stage. Leave with a half dozen new ideas to implement on Monday ... and if a speaker is bad, don't worry, he'll be off stage quickly.
Rethinking Process Improvement
Weaving together examples from general business, operations research, control theory and systems thinking, Matt Heusser suggests two areas of innovation: Process and Product. According to Heusser, companies can choose which, and how much, of these two to focus on, and he provides success and failure examples of both. Finally, Matt provides a new way to think about process improvement, grounded in the context of your company, its products and competitive environment.
Tuesday, October 31, 2006
Presentations II
I distinctly remember the advice I once got from John Bruce (on the blogroll at right) on how to improve my writing skills. In essence, he told me to search for the keywords "Bad Writing" on the web, learn the basic traps, and avoid them.
Once I find that I have read a hundred-thousands words of fiction inside a week, in my spare time, because the writing is just so good that I gobble it up, I tend to listen to what the person has to say.
And I don't have a lot of spare time, either. :-)
So in that spirit, I just read a post on presentations called "Please stop giving (cruddy) presentation"- by David Rogers. Check it out here.
Once I find that I have read a hundred-thousands words of fiction inside a week, in my spare time, because the writing is just so good that I gobble it up, I tend to listen to what the person has to say.
And I don't have a lot of spare time, either. :-)
So in that spirit, I just read a post on presentations called "Please stop giving (cruddy) presentation"- by David Rogers. Check it out here.
Subscribe to:
Posts (Atom)
