Blog Posts tagged with: nfjs

Oct 06 2009

Comments

NFJS, the Retro (Twin Cities Edition)

We had a terrific conference retrospective this weekend at the Twin Cities NFJS show. Eight people participated, with me facilitating. The conversation was good, and everyone left excited to implement the SMART goals that we chose.

As usual, we followed the basic structure from the Agile Retrospectives Book: Setting the Stage, Gathering Information, Generating Insights, Deciding What To Do, and Closing.

Setting the Stage

The NFJS conference retro is an odd beast: a sixty-minute retro embedded in a ninety-minute talk about using retros in your own organization. This poses a few special challenges:

  • The team needs to have a working agreement to occasionally "go meta" and talk about the mechanics of the retro during the retro. This risks reducing the value of the retro, but so far attendees have found it effective.
  • The team isn't really a team: it is a subset of the conference attendees thrown together for the first time to do the retro. So, the facilitator has to choose the activities in real time to match the size and composition of the group.

Sticking to the time box, we covered these ground rules in the first five minutes.

Gathering Information

To gather information, we used the team radar activity from the book. A few minutes of brainstorming identified about ten possible items to rate. That is too many to actually rate, so we used dot voting to narrow down to four items. Each participant used a Sharpie to make three dots next to the items they considered most important. As usual, the moving about the room helped people get engaged physically and mentally.

The items and their individual rating (1=worst, 10=best) follow:

  • meaningful content: 8, 7, 8, 7, 7, 7, 7
  • speaker quality: 9, 8, 8, 8, 8, 8, 9
  • track organization/session selection: 7, 8, 6, 6, 6, 6, 5
  • price/value: 8, 7, 6, 6, 8, 7, 6, 8

These numbers are quite high; overall possibly the highest I have seen at a conference retro. Also, the lowest scores were on track organization. When selecting talks for a conference it is almost impossible to please everyone, so while the scores were lower I was not optimistic about finding a useful recommendation. (Note that as the facilitator I kept these musings strictly to myself during the retro!)

Generating Insights

To generate insights we used the learning matrix. This exercise uses four quadrants (happy/sad/ideas/appreciation) to guide brainstorming. In the interest of space I will not reproduce the matrix results here: the information would be meaningless without pages of explanatory text.

Unusually, the "ideas" section filled up first. In fact, to hit the time box we didn't even manage to fill the other quadrants.

Deciding What To Do

To keep to our sixty-minuted time box, we agreed to dot vote for two items on the ideas list, and convert them to SMART goals. A SMART goal nees to be *S*pecific, *M*easurable, *A*chievable, *R*elevant, and *T*imely.

We ended up selecting these goals:

  • By February 2010, update the website and printed materials to include a single-line of text describing the "recommended audience." Free text might seem dumb compared to some kind of tagging, and it is delibarately so. We started to discuss a system of categories and realized that this would make the goal more complex, and therefore less likely to be implemented. Keep it simple.

  • By February 2010, run a birds-of-a-feather (BOF) session titled "What To Do on Monday!" Everyone agreed that the conference talks were inspiring, and included ideas that could create massive improvements back at the day job. But massive improvements are often beyond the immediate control of conference attendees, and it is frustrating to go back to work on Monday and not be able to start a new practice. The BOF will allow attendees and speakers to look across all the conference topics and generate a list of bite-sized ideas. If the BOF goes well, we will use it to generate an outline for a formal talk.

February 2010 might seem like a long way off, but since the retro was a breakout team that did not include the people who would actually have to implement the recommendations, it seemed wise to allow the work to be done during the winter off-season for the NFJS tour.

Closing

To close the retro, we did a quick thumbs up/down/sideways check to see if the participants found the retro useful. Votes were seven up, one sideways.

All in all, a good sixty minutes. I am excited about implementing the new ideas, and I think that the regular recurring nature of NFJS provides a great opportunity to close the feedback loop faster than at a conference that runs less frequently.

Recommended Reading

Jul 22 2009

Comments

Teaching retrospectives by example: NFJS Salt Lake City

Want to learn about agile retrospectives? Participate in one! At the No Fluff, Just Stuff software symposiums, I am doing a talk on retros where we begin by doing a retrospective on the conference itself.

At the Salt Lake City show this weekend, we had eight participants for the retrospective. NFJS talks are ninety minutes long, so we took the first sixty minutes to run a retro on the conference. Given that we only had a day of experience to retrospect on, and that we were not a cohesive team but were "thrown together" by people selecting the talk, I wondered if we would have enough to talk about. This turned out to be a non-issue, as everyone threw themselves in with gusto. We could have easily gone longer, and as facilitator I had to enforce the timebox on each phase.

Setting the stage

As an icebreaker, we did a variant of the Checkin exercise from the Agile Retrospectives book, using the question "If this conference was a movie, what movie would it be?" Answers included:

  • Driving Miss Daisy
  • Casino Royale
  • El Diablo
  • Lord of the Rings
  • Serenity

We had a few laughs, and the exercise broke the ice. However, nobody referred back to the movies in later exercises, so we will all just have to wonder if NFJS folk are orcs, reavers, outlaws, chauffeurs, or Quantum.

Gathering data

Next, we performed the Team Radar activity. After a few minutes of brainstorming, the team came up with eight possible topics to rate and discuss: prescriptiveness, (topic) diversity, relevance, scheduling, comfort, inspiration, food, timeframe. In order to hit the timebox for the retro, we agreed to use dot voting to select only four of these topics for further discussion.

Each attendee then ranked the four topics on a scale from 1 to 10, resulting in these averages:

  • 6.9 (topic) diversity:
  • 7.9 relevance
  • 5.9 scheduling
  • 7.4 inspiration

There were no major outliers on any of the scores. Overall, these scores are pretty high for a group who is taking seriously the challenge of finding things to improve.

Generating insights

Given the small group size, we elected to have a free form discussion to generate insights. Some of the ideas included:

  • Happy to see non-Java languages such as Clojure, Groovy, and Scala.
  • Would like to see even more non-Java, but ...
  • ... very happy that the Java topics were directly applicable to attendees jobs.
  • The agile talks were developer-focused, would like see more holistic talks.
  • For inspiration, the cornerstone is the first day keynote. Keynote was good, but could have been more novel.
  • Half of the participants had been to multiple NFJS conferences. The feeling of "it blew my mind" was still there, but not as strongly as in the past. Suggestion was made that this was the attendees changing over time more than the conference.

SMART goals are hard ...

The initial discussion of possible SMART goals attacked the lowest-scored item from the Team Radar: scheduling. How can the topics in a multi-track event such as NFJS be better organized so that participants are excited about every talk they attend? After a few minutes talking about track definitions, topic tags, website improvements, etc., we agreed it was a hard problem that was not going to yield a SMART goal in the time we had.

...Until you focus on the people

And then, by focusing on people instead of technology, we came up with two ideas that could significantly mitigate the scheduling problem:

  • Make it socially acceptable to walk out of a talk. Half of the participants said that, given a specific invitation to do so, they would have ducked out of at least one talk after they had seen the first few minutes and understood the agenda. So, at the next show, we request that all speakers choose a point 5-10 minutes into the talk to, well, invite people to leave. Keep count of the number of people who take the offer to decide whether this should become a standard practice.
  • Provide easy-to-find video on the NFJS website so that attendees can get to know each speaker before the show.

I brought the second idea to the conference organizer, Jay Zimmerman, immediately after the talk. He laughed because he is already doing it, building a collection of five-minute videos introducing the NFJS tour speakers. If only all SMART goals went so smoothly!

Wrapup

We voted up/down/neutral on whether the retro was worth the time, with all participants voting "up." The discussions helped each of us clarify our own perspective on the conference. Also, we were happy to have found easy-to-implement recommendations to improve the conference experience. After the retro, we had twenty minutes to discuss how to run a similar retrospective for an agile team, and some of the attendees are planning to try it with their own teams. As facilitator, I was pleased with the retro, and I am looking forward to taking this idea to other cities over the remainder of the year.

Resources

  • The Agile Retrospectives book includes dozens of retro exercises, and guidelines for when different exercises are appropriate. It is one of the books we recommend to team members on our projects.
  • Check out the agile talks at an NFJS event near you.

Jun 05 2009

Comments

Refactoring JavaScript, 2009 Edition

I am off to Dallas this morning to give an all-new version of the Refactoring JavaScript talk. This year, we will be looking at testing and refactoring jQuery plugins, using Screw.Unit, Smoke, and blue-ridge.

You can grab the slides here, but as usual the slides tell only a little of the story. Instead, grab the project itself, and use git's local history to start at the beginning and watch the refactorings step-by-step.

May 27 2009

Comments

Rifle-Oriented Programming with Clojure

If you come to Clojure from an object-oriented background, you may not know where to start. It is sort of like looking at a rifle for the first time and asking "But where do I put the arrows?"

Clojure solves the traditional problems of OO (and then some!) but it does it in different ways. To learn how to translate your arrows (encapsulation, polymorphism, and inheritance) into bullets, check out my new article in the May issue of NFJS, the Magazine.

Also: I'll be spending the summer on the NFJS circuit, talking about Clojure, Git, and other good things. Come see us.

Popular Tags