TL;DR – There are plenty of lean startup principles that can be experienced and clearly observed from participating in a hackathon event
Over the weekend (3rd July – 5th July) I competed in the 2015 Perth GovHack with a team that came together specifically for the event. Our project, #oncountry (http://on-country.org), is a site that aims to create an interactive map of Indigenous culture, history, and stories by pulling together information from a number of open data sources offered by various Western Australian and Australian government departments. For me personally it was a fantastic experience, not because we won one local prize and came runner-up for a second local prize, but because of the sincerity and enthusiasm all our team members brought to the project.
In this post I wanted to speak to the part that I played in helping to apply lean startup principles which I felt was one of the important factors to getting us to deliver a quality outcome in such a short amount of time. I drew a lot from the experiences I’ve had over the past 7 years in trying to commercialise Glyma, an enterprise knowledge management product that I envisioned and architected with my business partners at Seven Sigma.
First Night – Team Dynamics and Envisioning
The night before the actual hackathon began, there was an event for people to pitch and setup teams. It was at this event I first met all the people who would eventually become part of the #oncountry team – Leona, Les, Rebecca, and Tai (Richard, our sixth member, was unfortunately sick and couldn’t make it beyond the first night).
In my work as a management consultant, we focus a lot on setting up the right conditions and the right team. I can’t state more strongly how these two factors are the MOST IMPORTANT factors as to why I think we succeeded as a team even though we came from extremely diverse industries and backgrounds and had only just met. Without these prerequisites, no amount of following a lean startup methodology (or any other methodology) would save ANY team from failure.
Once we had our final team members together, we began the process of brainstorming what it was we were wanting to achieve for the project that weekend. Everyone was coming up with great ideas but I knew that with the limited amount of time combined with me being the only professional software engineer, we would be extremely hard pressed to get something technically complex completed. It was for these reasons I played the resident “a** hole” and posed slightly more critical questions and scenarios to push the team to chose a single, realistically achievable, value proposition.
Part of my decision process as to whether I felt a value proposition was focused enough was to consider the tasks that needed to be completed to create a very basic prototype within an extremely short amount of time. As we only had a total of 20 hours (people need to eat and sleep) to get something out, I knew that at most we could only afford a single iteration. The first goal would be prove the technology would work (in our case it was the datasets had the necessary data) to ensure what we wanted to do was technically possible. The subsequent iteration, after this initial goal was achieved, was to polish and make it production ready (in our case, ready for demonstration and submission to the judging panel).
Thankfully to the flexibility of the members of the team, and extremely valuable help from two of the data mentors in particular (Stephen and Jess), we were able to settle on a realistically achievable value proposition before the night got too late.
First Day – Project Initiation and Communication
Once we all arrived we got straight into creating our base prototype. From my many prior experiences on much larger projects, I knew that it was pretty important to be clear about task, roles, and process. Under these conditions (heavily time-boxed for both development, promotion, and presentation) it was even more important that we clarified these very early on. Certain members of the team were allocated software development tasks whilst others would work on analysing and cleaning the datasets we had available to us and considering whether they fit in our overall project narrative.
Collaboration throughout the entire day was extremely important. Again, this is more down to the members of the team and thankfully there were no wilting flowers or excessively bullish people in our team. Everyone was extremely enthusiastic about sharing any discoveries they made but were equally conscientious in informing and seeking out help from others when issues arose. Being able to provide continuous feedback to each other on directions we were taking allowed us to move extremely quickly and helped us overcome a major hurdle we all identified – we were doing a spatially based project but the cultural information we were provided had little or no spatial data and the spatial data we were provided had very little cultural information.
Pretty late on the first day, we had our first major win for the lack of spatial data in the cultural information. We realised that what we did have was spatial boundary information for a number of Indigenous land councils. These land councils often represented a major Indigenous linguistic group meaning if we came up with a basic converter, we could convert a land council name into the linguistic group they mostly represented. With this information, we could then query cultural databases (containing photos, books, music, articles etc.) to get information related specifically to a region.
None of this could have been achieved without continuous feedback to each other throughout the entire day and continuous questioning of assumptions.
Second Day – Execution and Finalisation
With the lessons learnt from the day before the team now had a clear path to completion. All ambiguities in the direction we had chosen had been clarified and the team was able to focus it’s efforts on executing the remaining tasks and delivering on time. The second day was considerably less stressful for us and I really put this down to the initial leg work we had done as a team to clarify a lot of our ambiguities at the introductory event on Friday night and the testing of assumptions that was done on the first day.
I honestly believe that if you are planning on starting the journey of a start-up business, you should definitely participate in a hackathon – even if you aren’t an engineer. It’s one thing to read books like “The Lean Startup”, but to be able to practice it and see it work on such a short time scale is something I wish I had experienced 7 years ago before embarking on my “Don Quixote-esque” journey with Glyma. The fact that the timescale was so short means that it was much easier to observe the principles in action, their cause and effect, and the team dynamics that contribute to either the failure or success of the project.