Being a keen reader of Garr Reynold's Presentation Zen blog, I had no choice but to follow his recommendation for taking a look at Al Gore's presentation on global warming on Google Video (Gore begins around 9:30 into the video). After watching the whole presentation, I can only repeat Garr's words:

See this film and you get to see a well designed and delivered presentation sans bullet points, and you may just learn a thing or two about how to save the planet as well. What could be more important?

Indeed, a passionate talk on an important topic and delivered well.

So the next XP conference is less than a month away. (It's not too late to register, if you haven't already...) This year the conference is organized in Oulu, Finland.

Yours truly will be co-hosting an activity with Markus Hjort, a colleague from Reaktor. We've prominently titled the activity as The Coding Tournament. It's essentially a hands-on learning exercise for XP engineering practices, masquerading as a friendly bot competition between teams formed from the participants.

What we're going to develop remains a well-kept secret until the beginning of the session but you won't be needing any super-advanced hacker skills in order to get the most out of the opportunity -- basic knowledge of the Java or Ruby language will do!

Paraphrasing Mike Clark: (I think. I can't find the quote anymore)
"Brain required, laptop optional" (although highly recommended).

As I mentioned earlier, I would've preferred seeing a 12-inch "pro" machine but the 13-inch MacBook doesn't sound bad. It's a bit heavy (over 2 kilograms) and has an integrated graphics card, but those are not necessarily showstoppers for me.

AppleInsider has some close-up shots as well.

Tempting...

Update:
Here's a photo of the size difference between the 12-inch Powerbook and the 13-inch MacBook...

All of us software types know that we should separate presentation from the underlying business logic. Still, most presentations we see in corporate settings--whether given by a suit or a techie--neglect this fundamental lesson of software design.

I've talked before about the way I recently started preparing my talks, writing a handout in essay form to ensure that I've got the big picture in check (apparently I haven't blogged about it, though, because I couldn't find anything on it with a quick search). I also managed to infect Vasco, I've heard.

The point I'm getting at is that I want my presentation to be more of an immersive experience rather than a competition of can-you-read-the-slide-faster-than-I-talk-it-through between the presenter and the audience. Thus, I write the handout with all the dirty details separate from the actual slides which are targeted at supporting the presentation, not being the presentation.

Witness slideuments.

The presentations we refer to as "Death by PowerPoint" are slideuments, monsters that try to simultaneously be a slideshow and a document. And we all know them by the winching pain we feel in our bottocks when we see one, bringing back memories from bad chairs and even worse presentations in packed conference halls full of co-victims.

It's not difficult to let go of your old ways of creating digital Frankensteins. It really isn't. All you need to do is to accept that there might be another way. Start respecting your audience and the time they're sacrificing in order to sit through your talk. That's all. The rest falls into place almost by itself with a little practice, trial and error.

Simon Baker's latest blog entry reminded me of something I've been thinking during some of my consulting gigs with organizations that are adopting Scrum but are relatively new to it.

To get directly to the point, I've got beef with the part of Simon's posting where he describes the three questions answered by every team member on the Scrum meeting:

It's not that there would be errors as such or that I would add a question. Nothing like that. Simon does a great job describing the Scrum meeting as it is described everywhere on the net and in the literature.

My beef is with the wording used everywhere on the net and in the literature.

You see, what I've found is that people are used to reporting progress to the project manager. (Can you believe that! We do something for a few decades and suddenly it's difficult to get out of the habit?) All sarcasm aside, I think the way we talk about "answering three questions" contributes to the difficulty of getting people away from reporting progress to the Scrum Master (who almost unanimously is the same guy who used to be the project manager before adopting Scrum).

"Three questions" is probably the easiest way to communicate what you're supposed to do. After all, you're asking yourself--and answering--three questions. The downside is that it doesn't seem to be the most effective way of communicating what you're supposed to do. Apparently words like "answer" and "question" tend to be associated with ideas closer to being interrogated rather than communicating information.

I can't help but think that some of the teams I've met on my journeys would've had an easier time if the whole three questions thing would've been represented using slightly different words. We all know what happened with Royce's waterfall paper. People scanned through the article, saw the waterfall picture, and failed to read the rest of the paper where Mr. Royce explained that the model described by the pretty picture would only work for the most trivial of problems. I'm afraid the same has happened in many places with Scrum's three questions--people take the bullet list and fail to pick up the why and to whom.

After all this whining, I guess it is only fair for me to make at least some kind of an attempt at improving upon the status quo. Behold, my suggestion for a replacement description of Scrum's three questions:

What do you think? Am I making a nothing into a something? Should I tell Ken to correct this horrible mistake with a new edition of the Scrum bible? Could you care less?