netsmith: December 2006

Tuesday, December 26, 2006

Lightning Talks

There is an interesting [new to me] phenomena which seems to be spreading through a few technical conferences. It's called the Lightning Talk (i.e. - Google Test Automation conference lightning talks).

The idea is that the conference provides a series of sequential 5 minute presentation slots with only one strict requirement: the talk must be 5 minutes or less. This has some interesting effects . . .

For the speaker . . .

It creates a sense of urgency because they must make their point(s) quickly

It lowers the barrier to entry for seasoned and newbie speakers alike - most 5 minute talks can be prepared more easily than 1 hour talks. It's less intimidating to prepare for a 5 minute presentation.

New types of talkes can be considered - A speaker can talk about some things that are more appropriately sized to a 5 minute presentation (a new idea you're just beginning to explore, a novel approach they need some feedback on, a quirky language behavior discovery or a rant on why they think something is a good/bad idea).

For the audience . . .

The speaker must really focus on getting their point across quickly.

If the speaker is boring or the subject is not as interesting as anticipated, there is an easy-out: just wait 5 minutes.

It gives you quick exposure to variety of speakers and topics in a short time frame.

I suspect a portion of the popularity of this idea essentially a 'market reaction' (a) getting stuck in long, boring, [often slide-driven] presentations (see [here]) and (b) people wanting to stay aware of the shear abundance of interesting topics and techniques being discussed.

Supplementing a conference with a one or more sessions of 'Lightning Talks' seems to be a win-win for the speaker and the audience.

The open space-based conferences have also been gaining some traction in technical communities. This looks like a fun one to be sure. Now if I could just figure out how a half day of ski-ing will help improve my [software development] agility . . .

Tuesday, December 19, 2006

Public committment, the neocortex, and metrics in software development

I've been thinking a lot lately about how sweeping organizational changes can be effectively introduced and sustained. Blue Ocean strategy introduced me to the concept of tipping point leadership but I was left asking myself: "How do you make it last?". Then I stumbled on this video of Kent Beck talking about "Ease at work". Deep in this presentation I pulled out this useful tidbit:

Ken suggests the following as requirements for sustaining change:

Make a Public Committment - to one or more people other than yourself

Make sure there is Accountability - the one or more persons you make a committment with, schedule a date/time to check back with you on progress.

I think using these requirements works incredibly well on an individual level, and to a lesser extent on a group level (i.e.- timeboxed iterations, sprints). That said, it's better to have something (committment wise) on a group level rather than nothing!

Also useful to consider here is the concept of fishbowl management -- that is to say: Put all your leaders in a fishbowl and begin measuring them to the same, publicly visible standards. You then reward and punish [demote] based on people's performance relative to those standards.

I also pulled out some names for behaviors I've seen before including the "organizationally addictive hero-matyr pendulum" and the well-named game of "Schedule Chicken".

"Schedule Chicken" is when everyone around the table knows the project will slip or that some piece of functionality can't be done in the necessary amount of time, but nobody is willing to say anything . . . the first one to say something loses the game, but in the end everybody is relieved when it's out in the open (unless there's someone at the table who wasn't playing).

On a side note, I found a podcast interview with Dileep George on some of his work constructing software to emulate the neocortex.
http://www.itconversations.com/shows/detail732.html
http://www.itconversations.com/audio/download/itconversations-732.mp3

Dileep's homepage of interesting stuff: http://www.stanford.edu/~dil/invariance/

If he and Hawkins can pull this off, it will certainly be the beginnning of a revolution in what types of problems we can solve with software.

Lastly, Valtech TV has posted some interesting presentations. I just watched "The Great metrics Debate with John and Amr - Part 1" (Part 2), and found it to be a well thought out illustration of good and bad points to various metrics we tend to push in Agile and what to watch out for when using those metrics.