Monthly Archives: November 2017

One Way to Run a Hackathon

Engineering, Internet Culture, Organizing Systems, Software Development

A place that I used to work ran periodic ‘Hackathons[1]’. After trying to describe them to various people it became clear that there were a number of different definitions of what a ‘Hackathon’ could (or should) be, so here’s my description, with some thoughts as to why structuring it this way might be a good idea.

Definition?:
What is a ‘Hackathon’? It’s a lot of different things to different people. Most definitions I’ve seen see it as an opportunity to spend a day (often 24 hours, or a weekend) building something that they wouldn’t normally build. The thing built is not necessarily a ‘thing’. It could be a website, and app, some other type of computer program, it could even be an organization. The important thing here is that whatever is created/built is taken from the concept stage to working prototype with at least some useful feature(s) by the end of the hackathon.

Purpose:
Why do you want to have a Hackathon? The ones that I’ve been involved with were an opportunity for people in a software organization to try something a little different for a day. Some reasons they did it:
– Learning a new skill or programming language by building something ‘real’
– ‘Scratching that itch’, solving some problem that they never quite get the time or priority to solve in their day-to-day
– Working with people that they don’t normally work with
– Building a full product (instead of working on a tiny piece of a huge system)
– Building a visualization tool
– Doing something totally different

Those involved generally seemed to greatly enjoy the experience, the chance to work on something different, to push themselves in a new and different direction, and perhaps the chance to receive the acclaim of their peers.

How did it work?:

There was a committee formed to organize the Hackathon. They were responsible for:
– Publicity
– Getting buy-in from management (this had already happened, so this part was relatively easy)
– Convincing judges to judge the competition (These were usually senior people in the organization who were not part of a ‘hack’)
– Organizing the various parts of the event
– The ‘pitch’
– The presentations
– The prizes
– The voting for the ‘Audience Choice’
– A/V and some method for telling presenters their time was up (we used a stop light)
– Finding sponsors for any ‘Sponsored Hacks’
– All of the various other small things required to run an event like this
– Buying the pizza for the party after the presentations

How often did they happen?
– The Hackathons happened once per quarter, generally in the middle of the week

Schedule:

During the weeks before:
– Publicity, book rooms, perhaps plan food, plan A/V, location, etc.

A couple of days before:
– Run the ‘Pitch Session’
– Provide a place (usually a wiki page) for people to join groups following the pitches

The first day of the hackathon (The hackathon would run noon to noon, with presentations 3-4pm the following day):
– Start the hackathon, giving any support where necessary

The second day of the hackathon:
– Collect presentations, so they can be presented in a timely manner
– Collect the judges, so they can judge the competition
– Run the presentations
– Run the ‘Audience Choice’ vote
– Count the ‘Audience Choice’ votes
– Distract the people with pizza while the judges are deliberating
– Help the judges present prizes

Some more details:

A ‘Pitch Session’ is:
– Each person gets one minute to talk about their idea, in the hopes that they can attract a group of people to work on it with them. There was a rule that teams had to pitch something if they wanted to win ‘best hack’, to encourage them to participate in the pitches and include others

How are teams formed?
– Teams can be of any number of people, but we never saw a team of more than 12 people or fewer than 1 person[2].
– To encourage different parts of the organization to work together, each team would be awarded points for each group represented in the team. Including someone from ‘Customer Experience’ or ‘Marketing’ would be worth three points, while including people from Engineering (the expected default for a hackday) would be worth 1 point
– Teams, once formed are added to the hackday webpage, for posterity, and so people can coordinate (and so the organizers can coordinate collecting all of the presentations)

What happened during the 24-hour Hackathon period?
– During the 24 hours of ‘hacking’, people generally put their project work aside and work on their hacks. Some people were given more or less time to do so, depending on their particular management chain and the urgency of their specific work at hand. Of course, if a production issue cropped up in the middle of the day, that would have priority.

How did presentations work?
– Each team was given 3 minutes to present. Luckily, we had a traffic light that was repurposed to give an easily visible signal to presenters when they were running short of time.
– There was generally an audience, of the other people hacking, the judges, and whoever else wanted pizza later

How were they judged?
– ‘Best Pitch’ (a friend of mine routinely won this part, due to his uniquely hilarious presentation style)
– This was generally awarded based on presentation originality and style
– ‘Most Productizeable’ (Which hack was easiest to productize for customers, either internal or external?)
– ‘Best Hack’ (this is the ‘best overall’ category)
– Not necessarily the one that won any other category, but the best overall
– ‘Best Presentation’
– Similar to ‘Best Pitch’, but generally a higher level of polish (and humour) is expected
– ‘Best Sponsored Hack’
– This is like ‘Best Hack’, but restricted to the specific sponsored category
– Hacks would be graded on the criteria above by the judges, IIRC on a 1-10 scale. (There may have been other criteria which were then rolled up into the categories above. That would be up to any event organizers, should someone wish to take these instructions and run with them.)

How did ‘Sponsored Hack’ work?
– This was a later innovation after some people saw the power of the various hacks that had taken place.
– A person or persons within the company would put up money for prize(s) for the best hack that would fulfill certain criteria. There was one hack to link a system to a particular enterprise solution, and one hack to use a new internal API that had been developed
– There was generally only one ‘Sponsored Hack’ per hackathon, and it was a bidding contest to determine which one would be the official ‘Sponsored Hack
– We found that having super-clear criteria about what constituted a ‘successful hack’ was extra important when the prize money for ‘Sponsored Hack’ greatly outweighed the prize money for ‘Best Hack’

What were the prizes?
– Generally gift cards of some type, glory, and a trophy
– The gift cards would be in the $50-100 range for first place. The glory was the really important part.
– Part of the trophy process was the expectation that each group would modify the trophy in some way before presenting it to the next team at the next hackaton
– We had some issues with one of the sponsored hacks when the prize money reached into the hundreds of dollars, because we had not clearly defined ‘When is a hack good enough to be considered a successful hack?’, and the difficulty of the particular hack

What types of ‘hacks’ did you see?
– There were a number of visualizations of various parts of the system
– There were a number of creative front-end interfaces for various parts of the system
– There was a one-line fix to a bug, in a effort to win ‘most productizeable’ by already being in production
– There was a musical number
– Once, the entire team of interns worked together on a hack
– We had an issue with not being able to tell whether our non-bookable meeting rooms were occupied, so one group made some lights with door sensors to quickly communicate down the hall that a room was occupied or not
– And many others…

Pleaes drop me a line if you want to run one of these. They’re a lot of fun, and can really help people get to know others and build an ‘esprit do corps’ in an organization.

[1]Unrelated: ‘Stupid Hackathons‘, which have a *totally* different ethos…

[2]Even the ‘Automated PowerPoint Presentation’ hack required someone to give the presentation.

How do you Run A Good Retrospective Meeting?

Agile, Organizing Systems, Software Development

I’ve written before about some techniques that I think help to run a good meeting[1].

Recently, I made the decision to delegate[2] the running of most of our team meetings to my reports. Typically, we have daily five[3]-minute standups, bi-weekly Sprint Planning, the occasional brainstorm, and a weekly meeting with stakeholders.

We now do a rotation, with each member of the team (including the interns) running the daily standups and bi-weekly Sprint Planning meetings in turn.

I’ve had to learn some things about delegating, but that’s a story for another post.

For today, I wanted to talk about some of my observations about how to run (what I think is) a good retrospective.

Normally, our retrospective is sandwiched in the middle of our Sprint Planning meeting thus:

1) Adjust any tickets which have changed status since the daily standup[4]
2) Close the Sprint
3) Retrospective
4) Choose a name for the new Sprint (Generally the most difficult[5] part)
5) Add items to the new sprint, prioritizing and estimating as we go[6]

It wasn’t until I watched others running a Retrospective that I understood a lot of the small things that I do that make a difference.

The (way I see) steps to a Retrospective are as follows:

1) The Facilitator draws the visualization[7] to start people thinking:

The facilitator writes something akin[8] to the following diagram on the board:

  
  Went Well       Not So Well
*---------------*----------------*
|               |                |
|               |                |  In Our Control
|               |                |
*---------------*----------------*
|               |                |
|               |                |  Not In Our Control
|               |                |
*---------------*----------------*

The point of this is to help the group think about and distinguish things that are in their direct control and out of their direct control. Many groups will come up with a definition for this after their first argument, often placing the line of ‘direct control’ at the edge of the group in the meeting/team in question. There are also many ways to write ‘Not So Well’, which I won’t get into, except to say that I prefer the hopeful phrasing. 🙂

Overall, you can think of your group process as bringing issues from ‘Not So Well/Not In Our Control’ to ‘In Our Control’, then ‘Went Well’, then noting new issues and starting the cycle again. We had one retrospective a while back where basically everything was ‘Went Well/In Our Control’, or ‘Not So Well/Not In Our Control’, so we ended up brainstorming ways to get things under our control, or at least influence, so we could fix them.

It’s not necessarily the worst thing in the world if most items are in the ‘Went Well/In Our Control’ category, but this may also mean that there are underlying issues that you may need to ferret out in your one-on-ones (You *are* having one-on-ones with your team, right?). One such issue came up recently in a one-on-one, and when it was brought up in the Retro., I hijacked the meeting for half an hour to have a specific brainstorm on that topic, to make sure it was covered in depth.

2) The facilitator asks the team to write things went well or did not go well on sticky notes and to put them on the board:

Each member of the team writes happenings from the past two weeks on sticky notes and posts them on the diagram. We use standard-sized sticky notes, and sharpies, so that the notes can be (mostly) read from across the room. My understanding of why this is done with sticky notes is so that people feel some measure of safety and anonymity, and therefore are more likely to express what they really think.

When running this part, I ask people to think along process lines. It’s helpful (and sometimes nice!) to talk about the fact that a particular project went well or poorly, but it’s often more helpful to talk about the parts of our process or other teams’ process that affected the outcome. Identifying process issues and fixing them is what really makes the difference here.

3) The facilitator clarifies each of the posts:

In some order, the facilitator goes through each (group of) post(s) and invites the author to clarify anything ambiguous, such that the whole group understands what each post means (often caused by my handwriting… :/ ). This should only take a few minutes. As they go, the facilitator will often do step 4). Along the way, some problems may be resolved simply by bringing them up, but some may require more thought/brainstorming. Those conversations are shelved until a later step by the facilitator.

As far as ordering, we generally talk about what went well first, probably for psychological safety reasons.

4) The facilitator de-duplicates the posts:

This is more of an art than a science. In some serious brainstorms, the facilitator will call a break at this stage, because it is non-trivial to get correct, while being quite important.

The goal is to group the posts into groups that are likely to have similar solutions. I don’t have good advice here, but it is often a good call for the facilitator to ask the group if two things go together, if they seem to sound similar. More insight on this will come with experience[9].

5) The facilitator decides whether to continue:

The facilitator decides whether any of the posts require a more in-depth conversation. This will likely have become obvious in step 3). You can always check in with the group, if you’re unsure.

6) The facilitator invites dot voting to determine the order for further discussion:

If there are multiple items to address, the facilitator invites the team to come up and ‘dot vote'[10] on which items they think are most important. A good number to choose seems to be 1/3 to 1/2 the number of items to be voted on. If people complain about the number of dots, you can change this, or remind/tell them that they can put multiple dots on items.

7) The facilitator counts the dots and orders the items in dot priority order from highest to lowest

8) The facilitator brainstorms solutions in descending priority order:

Starting with the item which had the most dots:
a) Make sure everyone understands what the issue is. If this is really unclear, you can brainstorm a list of ideas to try to get to the root cause[11].
b) Brainstorm solutions. Some of these will have obvious actions and owners. For things which are not so obvious, you may want to dot vote again.
c) Make sure you clearly write down (and perhaps make into tickets) any actions which arise.

d) Continue until no items with dot votes are left, you run out of time, or your group becomes unengaged.

That’s it! You’ve now run your first Retrospective. Let me know what you think in the comments below!

[1]Wow, I write a *lot* about meetings…

[2]Stay tuned for a post about ‘Power to the Edge’!

[3]Our daily standups are trending to the long side these days, perhaps up to 10 minutes, but people seem to find them useful, specifically the conversations to solve problems that can more easily be initiated when you know people are already interrupted.

[4]It’s always nice when people update their tickets as they’re doing things, but it’s not necessary. We’ve had success with doing it in our daily standup.

[5]I am not joking. Try it with your team and see for yourself. I went to an auction at a gaming convention during my youth, and the item which went for the largest amount of money was a book to assist people in making character names. Making good names is *difficult*.

[6]’Just-in-time’ planning. This also feels like a separate topic for a post.

[7]This is a whole topic. I like this particular visualization, but you could see that many others could work just as well. The following [8] is another.

[8]There are a number of ways to draw this. It’s sometimes good to change it up, to help people think about things differently. Another popular diagram is a ‘speedboat’ diagram, with wind, anchors, obstacles, and goals as the four categories. It’s not an exact mapping to the above, which has it benefits and drawbacks.

[9]I should write about this, too.

[10]’Dot Voting’ is where you give each person a number of ‘dots’ that they can place on the things they’re voting on. In this context, we use it to choose which thing(s) to talk about next. Some people insist on only one dot from each person per topic, some are more flexible.

[11]’Getting to the root’ in a Brainstorm is a really interesting topic. It’s non-trivial, and deserves its own write-up.