Building better products, faster, is deeply anchored into our DNA. We created an app to flatten the COVID-19 curve in Austria. It took us two days from idea to launch. How we did it, and what we learned can be read up in the following post.
Intro
At this point everyone has a story about the lockdown during the corona virus. Some of them are about the struggle with the extra kilos, some include drinking online with friends, and obviously you cannot avoid the videos around the “Zoom call went wrong” category. The first story I had is true to SQUER and shows the nature of our team #SQUER. Once the lockdown started, we already had the weekly online coffees introduced and moved our usual Friday breakfasts to the online space. But this was still not enough, we wanted to have more, something that allows us to do something interactively. Why not refocus our efforts to also do something productive and learn a new thing or two together? Thats how SQUER Hackathon #1 started.
The Vision - Ideation Workshop
Having collected a lot of experience in distributed and empowered teams enabled team #SQUER to avoid a high amount of up-front preparation effort. The team decided to have the first call on the first Friday of the quarantine to define the specifics. We decided quickly for 2 necessary cornerstones:
- Not to overcomplicate the first idea
- Concentrate on COVID-19 and what we could do to contribute
That gave us a very good idea where to go to and in a fairly short period of time the decision was made. For collecting ideas we applied a quick round of non-moderated brainstorming, which helped us detail the best ideas that came to mind during the ideation. As everyone in the team had already some experience with hackathons, we skipped the unnecessary introductions. The approach was held lean; list the ideas that meet the 2 criteria agreed upon and provide just enough details so that the team can get a glimpse of it. A quick voting resulted in picking the idea of building a tool that sensitises the user to act responsibly in order to flatten the curve. During this iteration we formulated the major acceptance criteria for the product:
- Easy to use and understand
- Helps the user to visualise how to adjust behaviour to contribute to flatten the curve
- Make the application sharable
With this completed, the methodology experts in the team made their recommendation about the next steps, during which the team opted for doing 40 minutes iterations followed by quick reviews. Also see how our Software Modernization services can accelerate your development process from ideation to launch.
Iteration 0 - The product blueprint
The iterations already specified deep dives in the main questions of the product design that required targeted expertise thus it made no longer sense to work together as a big team, rather than parallelly discuss them. The team was hence split into sub-teams working on separate preparation topics
- Team 1 - Design
- Team 2 - Factors and logic
- Team 3 - Applied technology
Each team got 40 Minutes to work in breakout sessions on their domains before returning to the group session and to present their findings. The 40 minutes were just the start of the conversation, but we did not want to risk to go to the wrong direction, and did a demo on our results during which we collected feedback. As the topic was fairly easy the main challenge was to collect the right amount of information and make the decisions required for the next step. Based on that each team adjusted their way of thinking and went back for an other round.
The next 40 minutes were spent with continuing the discussion in the breakout sessions. In this phase each team completed a basic skeleton of their respective areas following the agile iteration principle, by focusing on the simplest working product, and not on detailing one element of a complex future product.
A good example for that is how the logic of the application was built. First the team set up a main framework of weighted questions whose cumulated sum added up to a 6 stage “level” describing how advanced the user was. For the framework a mathematical model was required which was built on general virus spreading patterns adjusted with actual corona specific data (which was even more lacking back than).
The model was then applied to the first batch of questions that were also collected based on measures countering epidemic spreading and actual governmental recommendations. Also the design was just a mere wireframe that helped the developers accelerate building the baseline of the product.
The second 40 minutes have shown a growing efficiency as the members started thinking together and having a common understanding about the shared product. During the second review the solutions were already more advanced and prepared the members for the next; already longer iteration. We even had the first JS project with a working emulated solution by then.
Iteration 1 - Ready to Do
Normally in the first iteration (Sprint, Period, Phase etc.) the task list (backlog, kanban board) is already providing a clear view of the tasks. In this case iteration 1 - which the team has reached 3 hours after having started the hackathon - included setting up the scrum board for the members with rather requirement capacity (most of the team is well under way to - or has already - become real T-shaped, thus cannot be stuck into one capacity). The other half to the team with rather delivery capacity started setting up the right project and the development pipeline. Parallelly the developer account for this project was also created with Apple.
The beauty of this iteration was that the geographical and timely distributed work paid great dividends even on a weekend. As mentioned, the whole hackathon started on a Friday afternoon, and with iteration 1 we already scratched the evening. After the tasks mentioned above were defined, we split and everyone continued the “iteration 1” related work separately.
What made the quick iterations possible was the lean approach applied for the graphic design. The time invested into designing was always kept short. With this method the team got a look and feel of the application pretty quickly, could make decisions quickly regarding code base and navigation and based on the user experience of the team members and the ease of use in the application the design was being adjusted. The following examples show well that where the design journey of the app started.
Until the end of the iteration on Sunday evening the following tasks were completed:
- App design created
- Texts written in german
- Logic and weighting of the responses were created
- JS project was created
- Pages were created
- Logic was implemented
That means, by Sunday evening we had a working product (not a wire-frame, but working code!) with premature design, bugs, typos but it worked and could be tried!
Iteration 2 - Doing the doing
In this phase we were working similarly to a usual development team. Even though we had no meetings (not even dailies) anyone who had a couple of hours to spare, picked a story from a backlog, and worked on it, then merged it to the master and let the others know in the channel so that anyone could test the new version. Similarly, the team members who had the time to test checked for glitches and updated the developers about the found issues who could right away go and fix them.
Unfortunately, in this phase we also had to learn that uploading a health / COVID-19 related application to the Apple Store will be scrutinised even further and will take longer as the usual 5-7 working days.
Thus, as so often in a product development process, we had to look for an alternative in order to stay relevant and decided to publish the solution as an emulated application on desktop, and created http://curveflattener.com which is still online and can be visited.
Takeaways
Within the first 2 weeks the application had almost 3000 visitors, which was also boosted by Manuel’s (one of SQUER’s cofounders) appearance on the KroneHit Radio in the “Corona Heroes” show.
There were no further iterations as the landscape changed on a daily basis and we had to focus on our respective projects. But the hackathon provided the team with more than one big learnings.
- Even a bad situation can be mitigated if the team remains motivated and has the drive the create something together!
- If the right people have the right motivation who work in a proactive and cooperative manner, they can come very fast to a good enough solution.
- Experienced and empowered teams need less processes as proactivity makes up for lack of organisation and keeps the approach possibly light. Using agile development methodologies can help a team to arrive from ideation to a product in just a matter of days (or hours!). This period varies greatly for each topic, it might well take longer if the product domain has a considerably higher level of complexity.
- It is possible to work without tight moderation, however all team members require a deep understanding of the applicable processes and need to respect the team decisions made in the process!
- Hackathons are not only for developers! Having people with requirement capacity (Business Analysts, Product Owners even Scrum Masters) in the team enriches the understanding and accelerates designing the solution.
Struggling with the output of your team? Contact us and let us help you increase your efficiency! To find out more about increasing efficiency in complex projects and how a modular banking solution can contribute to this, read our article 'Boost efficiency through a composable banking system'.
