Hackathons are starting to overlap with (and displace) Proof of Concepts as a means of proving out technical approaches to business problems – but what exactly is a Hackathon and how does it operate? This post will provide some thoughts around what makes for a successful Azure Cloud hackathon based on real experiences and will focus on one specialised form of Hackathon, the Hothouse
Along the way we’ll lay out the key aspects of a hothouse, show how it differs from the standard hackathon and cover some of the key Azure technologies that work well in the tight schedules of this approach. These technologies take away much of the configuration and infrastructure work allowing participants to focus on functionality.
Benefits of a Hothouse over PoCs
Typically, the kinds of activities undertaken in hackathons or hothouses would previously have been run as Proof of Concept exercises however these PoCs may themselves turn into mini projects lasting several weeks. This alternative looks to achieve comparable results using a radically different approach:
- Delivery in a few days rather than several weeks – the Hothouses lasts about 3 days at a maximum and is intended to deliver results at that point
- Close communication between business & IT – the 2 groups work together directly within the same team
- Highly parallel – around 4-6 teams work in parallel (with some cross fertilization of ideas) to create potentially unique solutions to the problem
- In at the deep end – IT teams are asked to rapidly gain knowledge in the underlying technologies
- Strengthening of working relationships – having the Business & IT teams work in close proximity ultimately leads to a better understanding of each other’s viewpoint
- Sets up final accelerated delivery – at the end of the process there should be sufficient progress to pull together a “best of breed” approach for the actual delivery (usually around 90 days after the event)
The process is undoubtedly taxing, but ultimately very rewarding, not least because a) it enables the IT team to get real world experience in a range of Azure technologies and b) it gives the business users an insight into the “art of the possible” (a somewhat overused phrase usually but very applicable here).
Hackathon vs Hothouse – what’s the difference?
So firstly, what is a hackathon? Well, Wikipedia says this about them:
“The goal of a hackathon is to create usable software. Hackathons tend to have a specific focus, which can include the programming language used, the operating system, an application, an API, or the subject and the demographic group of the programmers. In other cases, there is no restriction on the type of software being created.”
Generally, hackathons have a focus around a given technology or platform with the aim being to deliver “usable software” at the end of the event. (Note: This software is unlikely to be production quality but should be sufficient to prove out the technology and approach). Either individuals or teams take part with the goal being to work towards multiple potential solutions in parallel. Typical features of a hackathon include long days, endless pizza and caffeine, a lack of sunlight for the duration and intensive coding.
Recently however the authors attended an Azure centric “Hothouse”. The hothouse approach is similar in many ways to a hackathon however there are some aspects which differ:
- A very specific business problem drives the focus and direction of the event
- This problem is not revealed until the start of the event, and even then it is revealed in stages
- Teams are made up of a rich mix of business users & technical specialists
- There is strong business sponsorship throughout
- The hackathon will set the stage for a follow on, 90 day production level development
- Teams present real, code based progress every day (in a very narrow time-slot)
There are several definitions of hothouse however this article largely describes the overall approach.
At our event almost all team members stayed in a nearby hotel and socialised in the local bar each night. This social bonding aspect shouldn’t be underestimated, it may be the first time that many of the team members have met socially.
Outline of event
The hothouse event will likely be from 1-3 days with 3 days being ideal. At least 3 teams will be needed of around 4+ members from a range of disciplines. A particular feature of the Hothouse methodology is that the problem statement is not revealed to the teams before the event starts, which creates a healthy buzz and an atmosphere of constructive tension, and also prevents preconceptions on how to approach the problem. This, and the strict time-limits on when to present and for how long gave the event an air of “managed stress” for want of a better term.
The general approach is to reveal each part of the problem statement early each morning, ask each team to present their results in the early evening, and allow some time at the end of the day for further work. As you may have 6 or more teams presenting, rigorous timekeeping is needed, 5 minutes for presentation followed by 5 minutes for questions equals 1 hour in total, so this is probably the max you’ll want to keep to (in fact 3 minutes for presentations and 2 minutes for Q&A at the end of each day is not uncommon).
Pick your Problem
The core of the event is the problem statement, the actual overall business issue or opportunity that is driving this activity, therefore it’s important to spend some time on this. As an example a data-focused business problem might be:
- Overall – Identify most profitable customers in organisation to improve marketing efforts – this then breaks out into 3 sections
- Day 1 – Create a single view of customer across multiple business applications and eliminate any duplicates
- Day 2 – Discard customers who score highly for having a high chance of retention
- Day 3 – Identify most valuable but least loyal customers, i.e. those customers with highest potential profit but which have a profile indicating they will churn easily
A key feature of the hothouse approach is this potential change in priorities each day. for example above in day 2 we’re told to discard customers who will stay with the organisation anyway (something not necessarily intuitive given the first phase). This switch in objectives can change things up and add to the constructive tension (as frustrating as that might be if you are in one of the teams 😊).
In any case, the problem must have a clear overall objective and it should be obvious what success looks like. Again, it must be solvable in 3 days, so potentially be prepared to simplify and fine tune as the hot house proceeds.
If it turns out the problem is not solvable in the time it is vital to that any innovation developed during the process is captured. The deliverable for the hothouse is not actually the finished piece of work from each team but instead the building blocks and insights built by each team.
Preparation is key to a hothouse event. In this vital planning phase consider the following items for your checklist:
- Get offsite – it’s important that the hack/hothouse is carried out offsite in a location that’s suitable. In our case this was a wide-open area which held all 6 teams and had plenty of whiteboard/flip-chart space. You’ll also ideally have a separate amphitheatre-type area with seating for all team members, so that each team can present their work daily.
- Secure your partners – to maximise success you may want to engage with a partner who has experience both in facilitating hackathons and in Azure Services, to help the event progress. If you’re smart the partner might be able to supply the off off-site venue as well.
- Long days – Set expectation of long but challenging & and interesting days. The hothouse represents a considerable investment and so by definition a longer day will achieve more.
- Phones off/Calendars fully booked – Hothouse must be dedicated time, if anyone drops out for a meeting or phone call this will impact the momentum for their team.
- Supply food & and drink – make people comfortable, provide (ideally healthy) food and drink and seating areas away from main tables.
- Scoring – how will you score each day and how will you define a winner? Whichever method is used it may be useful to have a “winner takes all” scoring system at the end so that any team has a chance of winning. Another option is to present side prizes for “best pitch”, “most unusual approach used” etc to spread the goodwill and reward risk taking & innovation. In any case define your scoring approach up front and make sure the teams understand it.
Scoring: In our hothouse everyone was given 1000 points to allocate across the 6 teams using post its on each teams name. There was an honour system which said you shouldn’t use your points for your own team. I’m not sure that was strictly followed in all cases…
- Twitter and marketing – Get your event on the twitter-sphere. Create a hashtag for the event and encourage all participants to tweet on a regular basis. Perhaps have a “best tweet” award. Consider having a tweet wall, a live twitter stream of your hashtag on a large screen
- Roving reporter – allocate one or two people as event reporters, gathering testimonies and experiences and taking photographs (and get them to tweet regularly over the event!)
Technical preparation steps
That sets up the overall event for success however in addition to the above there are specific technical preparation steps which can also help ensure a successful outcome.
- Technical awareness – Ensure technical people are familiar with Azure Data Services and have run through some labs or otherwise gained experience of the technologies involved. The main Azure services suitable for hackathons are not difficult to pick up, however there is always some learning and so it’s important that the technical members can hit the ground running. Consider producing Azure “cheat sheets” with tips on configuration etc.
- Create the environment – Create an isolated fully-functioning Azure environment (perhaps with its own Azure Active Directory set up). This environment can then be torn down after the event.
- Identify the data – Get clearance for any data that will be accessed during the hack, both for internal & external team members. Most likely the data will be anonymised and made suitable for external viewing.
Having the appropriate team mix is essential as each team is designed to be self-contained. Teams should be defined prior but can be revealed on the day.
- Mix of business representatives, Business/Data analysts & IT developers – It’s vital to have business people on each team who have a good grasp of the business problem and can guide the rest of the team.
- Azure Technical Expertise – Although all technical staff should be familiar with the relevant Azure technologies deep expertise may be needed at times. It’s useful therefore to have technical expertise in Azure on hand, either 1 per team or floating resources who move between teams.
- UX/UI Expertise – if there are UI components in the hack ensure that you have some UI/UX expertise in each team.
On the day
At the event, a sense of healthy competition will be helpful as this will drive innovation. As mentioned the space is also very important as people will be spending long days in one place.
- Create a buzz of competition – have scoring and leader boards with prizes for the winners. Have a “winner” each day as well as an overall winner.
- No secrets – Ensure all discussions of solutions occur in the main room. The greatest value will occur if all teams move towards a successful conclusion therefore eavesdropping & stealing of ideas is actively encouraged 😊
- Set the cadence – in the morning, reveal that day’s section of the problem statement to all teams and set a time for presentation of results. Potentially set additional checkpoints (such as deliver an outline architecture or intermediate results). Ensure the business objectives for each day’s section are clearly articulated.
- Work the room – get your roving reporters out asking the teams how they are progressing, getting testimonies, tweeting successes & taking photographs.
- Stick to the time limits –have a timer visible and ensure each team sticks to their 3-5 minutes to present.
In our hothouse event timing was actually brutally efficient. As soon as the time hit 5 minutes the audience started clapping, regardless of where you were in your presentation!
- Code not PowerPoint – Daily presentations of actual working code & progress should be encouraged – not PPTs
- Intermediate guidance sessions – the only formal touch points are the morning problem reveal and the evening presentations. However, to maximise value from the day you may wish to have additional guidance sessions
- Pitch guidance – what to present, how to keep pitch within time-slot
- Short meetings with mentors to evaluate progress informally
- Clinic – 1-hour session with Azure SMEs to advise on blockers, areas of interest, technical suitability of solutions etc
Our hothouse event featured a lot of AI & Machine Learning – there’s several options for this on Azure however so all Azure SMEs gathered in 1 room and made ourselves available as a “drop in clinic” for an hour in the middle of the 2nd day. This removed some blockers and helped the teams progress.
How can Azure help?
Time to market is critical in a hack and this is where Azure Services can greatly accelerate the delivery of prototypes. With the inherent time pressures simplicity is key, for example although a full- blown Machine Learning model may be needed for production potentially Azure Cognitive Services (out of the box AI APIs) or Azure Machine Learning Studio (Machine learning workflow environment for Citizen Data Scientists) may be sufficient to demonstrate the concept. Here we cover the Azure tech that can provide the building blocks of a successful hack.
- Web hosting – WebApps – WebApps is the Azure PaaS (Platform as a Service) for deploying, well, web apps. Straightforward to use and simple to deploy this service will most likely provide any necessary application UI.
- Workflow – Logic Apps – Logic apps is a technology on Azure that can build simple to moderately complex workflows. It can be event driven (for example a workflow can start when an Email arrives) and is a very straightforward tool for putting together pieces of code very quickly.
Virtually every team in our hothouse discovered Logic Apps fairly early on (OK we may have given a few hints) and virtually all of them used it as the backbone of their delivery.
- Logic – Azure Functions – Azure functions allow serverless code to be written and delivered. Multiple languages including C# & Java are supported and Python is also available. Functions can also be triggered by multiple Azure services including Azure Streaming Analytics, Cosmos DB and of course Logic Apps.
- “Out of the box” Machine Learning/Artificial Intelligence – Cognitive Services – Azure Cognitive Services provide an out of the box evergreen set of APIs for ML&AI. which need no training or set up. Capabilities include Key phrase extraction, sentiment analysis, face recognition & OCR. They can be plugged together easily into a workflow to demonstrate (for example) image analysis or speech recognition
- Intermediate ML/AI – Machine Learning Studio – If more customised ML/AI features are needed ML Studio provides an entry level option. Although some data science experience is needed, this may well be sufficient for the needs of the hack/hothouse.
- Data Visualisation/Data Mashups – Power BI – Power BI is an incredibly effective data visualisation tool however it is also an excellent data mashup tool. Although conforming data sets so that they can be co-located & and merged is likely best carried out in ETL logic in production, Power BI can perform effective data shaping on the fly for a prototype.
- RDBMS – Azure SQL DB –Azure SQL DB instances can be spun up very quickly. These are fully fully-functional databases and can be used for OLTP work or small-scale Analytics.
- General data sink for app state, messages, non-structured data – Cosmos DB – your code may need polyglot storage or even simple persistence of state. Cosmos DB is a PaaS service which can be used to host JSON documents, key-value pairs and graph data, without any complex set up being required.
- Natural Language – Chatbot– If a natural language interface is needed the chatbot framework can be used for general purpose needs (note, Power BI also has a natural language interface though this is designed to only work in the narrow confines of the current Power BI Data Set).
There are other services that may also be of use in the hack/hothouse however these capabilities will probably be at the heart of your prototypes. Quick to learn and deploy and with no infrastructure to worry about they will help you get up and running in the event very quickly.
The team operation is crucial as there is little time each day for pondering solutions. The following considerations will hopefully help each team operate smoothly and avoid dead ends.
- Have a Leader – ideally from the business but in any case, each team should ideally have a “soft” leader. Generally, people should be encouraged to work collaboratively however sometimes a leader is needed to bring in lone wolves (see below) and for Triage (see below).
- Focus – the deliverable is code, not a PowerPoint deck describing the problem. Spend some time discussing the context and background but get to coding as soon as an understanding is reached. Therefore…
- Avoid Analysis Paralysis – the problem will likely be fascinating and potentially long standing and n particular the business analysts on the team may have strong views on the issue. However any one direction and approach, however poor, is better than 3 excellent but competing approaches.
- Agree direction & have checkpoints in the team – ensure each team has a regular checkpoint to set direction, prioritise and set tasks.
- No lone wolves – each resource in the team is precious, however some technical types may like to disappear into their own sub project. Don’t let them, ensure they are working as part of the overall team.
- But don’t have too many hands – 2 people working on one task is probably the max, any more and discussion can take over.
- Have ruthless triage – This is particularly important. Any hack will involve multiple avenues of exploration, and when you’ve worked on a problem for 36 hours it can be hard to let go. However, some lines will be dead-ends, others will work for the production delivery but not be completed in time for the end of the event. Apply triage regularly, assess each piece of work and make an honest assessment of its chances of success. Be prepared to have the hard discussion around dropping lines of enquiry that are just turning into a resource sink.
In one of our teams we were not great at applying triage. One line of enquiry around Machine Learning & classification was fascinating and was constantly 60 minutes away from delivery. But in the end, it couldn’t quite get there, didn’t really play a part in the final delivery and meanwhile this particular investigation had consumed a talented resource for most of the event. We should really have pulled it on the 2nd day.
- Smoke & mirrors are OK…as long as you are confident the technology would meet the needs given more development time. In this event it’s probably OK to do a little “screen print” sleight of hand, however, overselling the technology doesn’t help anyone. Expectations will be set by demonstrations, so those demos have to be realistic.
Once the Hothouse is completed it’s time to wrap up and summarise the event.
- Find your winner – if you’ve been scoring and a winner has emerged, then shout them out & and award their prizes/gold coins/Bottle of cheap Cava.
- Recognise everyone’s contribution – the chances are that every team has contributed something interesting or ingenious. If possible, call out these items for recognition as well, and in particular…
- Recognise innovation – the teams may converge on the same technologies and overall approaches. Try to find some way (through scoring, prizes etc) to encourage independent thinking and reward true innovation.
- Keep it light – everyone has worked hard; some people will have hit brick-walls and be feeling frustrated so try to keep the atmosphere light with an “everyone’s a winner” atmosphere.
- Emphasise collegiate lessons learned – the final production solution will draw on the best across all teams, not just the result from the winning one.
It’s essential that momentum is kept so that the results of the Hothouse develop into solutions:
- There should be a plan in place to deliver a real-world solution from the hothouse, ideally no more than 90 days after the event
- Review the work and tease out lessons learned – look at the results from all teams and pull out the best of breed. Ensure a meritocracy of ideas mentality is utilised so that the best ideas and concepts are surfaced, regardless of source.
- Re-scope the delivery – based on the amount achieved in the hothouse, re-scope the work up (or more likely down) to fit realistically within the 90 day period
- Identify the tiger team – pull some of the most successful team members together for the delivery team, those who demonstrated either particular technical skill in this area or an instinctive understanding of the problem. However, also use this as an opportunity to train up less experienced or confident staff.
- Kick off the actual deliverable – Define the approach (most likely some form of Agile), name the members, deliver the scope & and launch the project. Ensure that something worthwhile is delivered within 90 days.
- Demonstrate and circulate results inside the organisation, including all relevant stakeholders – so that the value is proven and there is increased likelihood of adoption. This is where any testimonials, tweets and success stories can be helpful
That’s it, once you develop the cadence with Azure’s help you’ll find you can achieve in 3 intensive days what would normally have taken 3-4 weeks in a formal PoC!