Following Tauberer (2018), the hackathon project should address a defined problem and could even present a part of the solution. It should be of a challenge that can be solved during the timeframe of the hackathon, so that participants can get a feeling of achievement.
During the Baltathon events we found however, that defining the challenge too narrow and too problem oriented, though has an impact on motivation and creativity. An experienced participant said the task was too “business” oriented and not free enough.
For Gdynia Aquarium, the briefing was an app that includes a kind of game. In the warmup, problems of aquarium were highlighted. The aquarium asked to develop a game that solves problems (e.g. people getting lost). This resulted into comparable results, with most groups focused only on the problem in a very narrow sense, some even not considering the gamification aspect. The conclusion was, that a freer task would have caused more creative ideas, but these might be difficult to implement. With such a problem based briefing of participants, rather achievable ideas were developed, however, not very innovative.
For Experyment, the briefing was to develop an app. During the warmup, results of a survey of guests and the museum team were presented. Following a design thinking approach, the science center had identified personas to focus on, based on the survey. Experyment presented problems that the guests encounter in the exhibition, and asked the hackathon participants to solve these problems (e.g. exhibition seems to be for kids, not for adults; or how to use exhibits, how to provide instruction – although the description is available people often don’t read it). The museum team even suggested how to solve the problems already during the warmup. During the warmup, the strategy of information was changed as participants seemed to be overwhelmed by expectations. The second part of the warmup was then dedicated to gamification. The Experyment team concluded that clear and high expectations seem to limit creativity. For the future they would recommend to provide input only about their institution in more general sense and leave the participants more freedom, to receive more out of the box ideas. The team also proposes to stay in touch with participants after the event, to invite them again or involve them in what happens next or ask them to first test the later developed application. They confirmed the satisfaction with the general organization and the exceptional teamwork in the project team. However, how to take the results from the event further to real developments seems a challenge.
The Lithuanian Sea Museum focused their briefing on a selection of potential topics and problematic issues. Upon post-event reflection, the topics seemed to include already solution. The topics were promotion, marketing, a game or a product provoking an engaging exploration of one of the exhibition houses. Problematic issues were for example the distribution of visitors along the route, navigation, multilingual, seasonality and online ticket promotion. While gaining considerable experience and learning about potential partners, the museum did not feel to receive creative ideas for their further app development. They expected a functional concept for a product – a BYOD-guided tours providing an enhanced visitor experience during and after the visit. Expectations for unexpected solutions were high. However, the participants presented ideas that were already known by museum staff and very similar to their own solutions. The event format is though very promising to the museum, as uniting museologists and the IT sector. But communication has to be facilitated, in the chosen format contacts were rather little, so the mutual learning remained minimal. Ab advice for future hackathons would be to have representative from the museum as an obligatory member of each team during the whole process.
The concept used to derive the task for participants was done through following the Generic Learning Outcomes (GLO) process. From this process the goals for the hackathon were defined. One session had been conducted with the project partners, one with students/school pupils at Malmö Museums and one at NaturBornholm to come the expected outcomes. The outcomes defined by the project partners were given as a briefing to the participants.
“The chart below tells what we want our visitors to feel, think, and do when they are using our Bring Your Own Device (BOYD)-tool, during and after the guide.” (from the briefing for Malmö Hackathon)
|Knowledge and understanding||Different kind of learning experience.
Add additional content to the visit, that are not available without the tool.
|Skills||I will be able to use the tool with ease.|
|Attitudes and values||I will have a feeling of freedom by the possibility of an individual guide|
|Enjoyment, inspiration, creativity||I will have fun, be curious and want more.|
|Activity, behavior, progression||After the guide I will behave in a more environmentally friendly way, specifically regarding the Baltic sea.|
GLO Table used for Malmö Hackathon
The team of Malmö hackathon evaluated the results of the hackathon giving basic ideas and inspiration, however, no final solutions were produced. It can only be understood as an input for a longer process. The workload and effort in organizing the event has to be balanced with the results expected. What the team recommends was working the GLO process to better understand users and the own organizations expectations, and use these to define the challenge. To increase both participation rates and efficiency, a collaboration with other (tech) organizers is recommended.
Overall, the team was satisfied with organizational part of the hackathons, despite being challenging for the museums. Learning and resulting recommendations will follow in the coming chapters for organizing a hackathon. More difficult to judge was the evaluation of the hackathon results. This can be explained by the differing expectations. In the hackathon conditions it was broad, by naming ideas, code or ready solutions as accepted results. However, not only museum staff had different expectations, but also participants, if coding is in focus or general idea development and presentation skills.
There seems to be a tension between readily implementable though not surprising solutions on the one hand and innovative proposals of high creativity on the other hand. The problem solving oriented briefing in the hackathons with even presenting own solutions by the organizers resulted into no “out of the box” ideas. Moreover in the setup, there was little interaction with participants who mostly worked for themselves silently. Getting more involved in the creative process could have provided the museums with further insights into ideation.
As Tauberer (2018) said: „Don’t expect to have actually solved a problem by the end of the hackathon. Think of the hackathon as a pit-stop on a long journey.” It was a major insight that a hackathon is one step in the process of creative problem solving. Jarvis (2012) argues for alternating divergent and convergent steps in such process. In his problem-solving model, after assessing the situation and exploring the vision, the challenges shall be formulated. For the museum hackathon concept, for this step we propose the following partial steps:
- Define the Goal of Hackathon
- Define the Target Group of Hackathon
- Define the Hackathon Challenge
- Define the Communication to Target Group
- Define the Jury Criteria
The following step “Exploring ideas” (Jarvis 2012) is the hackathon event, in this case understood as supporting ideation by involving other groups of people aiming at providing additional ideas. The formulation of solutions (Jarvis 2012) is only done in the next step of the creative problem solving process, meaning after the hackathon. This step however assumes that the overall vision was explored and challenges to solve clearly defined, in order to objectively identify most promising solutions for implementation.
- What do you expect to get from the hackathon? (e.g. contacts, creative ideas, problem solutions, prototypes, learn) Define your targets! How will you know, if the hackathon met your expectations?
- How do the selection criteria for the winning teams of the hackathon link back to your targets?
- Who are the “right” participants that help you reach your targets with the hackathon? (e.g. tech enthusiasts, visitors, school kids, professional programmers)
- What will you do with the results?
- How should a result look like (code, idea, …) that you can further use it?
- Is the hackathon part of a larger process? How will it fit in, will you be in contact with the hackathon participants after the event?
- What is the value of the hackathon for your organization?
- How does it fit with your general innovation strategy?
- Consider deriving answers to these questions by involving visitors/users with the GLO process.
DOWNLOAD FULL TEXT
Jarvis, D. (2012) ‘MGT567 Creative Problem Solving’ [online], available: https://www.slideshare.net/dajarvis/mgt567-creative-problem-solving [accessed on 16 July 2018].
Tauberer, J. (2018) ‘How to run a successful hackathon’ [online], available: https://hackathon.guide/ [accessed on 12 June 2018].