Let’s for once do what we enjoy. Read a story how we almost forgot that we were working in a huge corporation and tried to deliver new product in one straight week of fun, motivation and hard work. I prepared a cookbook for those of you who want to try it for yourself to avoid pitfalls we fell into.
Who are we? This question was already answered by Jarda Machaň in his article about a challenging journey to innovate in the biggest Czech bank. Just like in any corporation, there are many smart people bored by routine work and realization of almost any ideas is like a long distance run. It was an impulse to reward us at the end of the year and try another way of agile working. Our motivation was:
- Expand a new idea with interesting potentiality
- Try new technologies
- Try a new way of working than Scrum (God forbid Waterfall:))
- Relax and fun
Everything Starts with an Idea
We have been flirting with an idea of using smartwatch for advanced authorization of bank payments (I do not want to dive into the details about the solution because the article mainly concentrates on how we achieved that).
However, if you come up with such kind of idea, you should usually confirm that your idea is not a waste of time. And that is how our project started. We made a team where four members were originally developers or solution architects, one was a scrum master / analyst and one was a product manager. The methodology chosen for research of the idea was Value Proposition Design (VPD) by Strategyzer and we organized a mid-day workshop which was fruitful for many reasons:
- We arranged everyone’s thoughts and became aware of the topic
- We became buddies:)
- And above all, we determined a target group and hypotheses of our idea
One Week Hackathon vs. Design Sprint
Inspired by hackathons we wanted to try for the short-term project popular Design sprint framework (DS, known also as Google sprint). However, VPD workshop pointed out it could be foolish. The reason is that the DS is business-oriented framework and it is focused on extending the existing solution, whereas we wanted to code and develop a prototype of our new idea. So we elected One Week Hackathon which, in contrast with DS, is more flexible and reminds of a speed Scrum.
Warning: the following text contains customized framework designed for our company. Our inspiration and the only source that we found was an experience from hotel search company Trivago.
Fortune Favors the Prepared
So, we had the idea, team, chosen methodology of working and many hypotheses. The first thing what you need to do in a corporate is to clear out you calendar and find a fancy place for a week. Eventually, you just need to get the obvious but important working tools such as flipchart or whiteboard, hardware (in our case smartwatch), sticky notes, markers and LET’S GET THE PARTY STARTED!
Monday — Setting up the Rules
The following topics were on the agenda of the first hackathon day:
Team & Roles
- 1 Product Owner
- 1 Backend Dev Lead
- 1 Frontend Dev Lead
- 2 Developers, Analysts
- 0 “One Week Hackathon Masters”
… this is how team role were defined.
Retrospectively, it was a bit useless to assign any roles to our project team members because, as we went along, the roles were divided by themselves: product owner, developers by platform, documentarist / organization support. Lead roles (including OWH master) were unnecessary because the cornerstone of the team were seniors.
Sprint Rules and Schedule
Every day (except Monday) there was one little sprint inspired by Scrum:
- 10:00 Stand-up (Daily Meeting) + setting up a day (sprint) goal
- 12:00 Lunch
- 15:30 Sprint Review + Planning Meeting — used to summarize the day and plan tasks from backlog for the next day. On Friday there was longer Retrospective Meeting instead.
- 17:00 End of the day (sprint)
The week after were arranged a demo presentation for our colleagues from Ceska sporitelna.
Tools
We used physical Kanban board for task management: rows for people, columns for days. We worked closely together, so we did not distinguish states “to do” and “in progress”. Backlog and done issues were placed separately.
Other tools: Slack for communication, Google Drive for documentation, GitHub and Azure for development as such, and Spotify for Christmas background.
Project Vision & Success Criteria
Brainstorming parts are coming — we determined three main visions that we wanted to achieve. We divided them into smaller goals and defined their success criteria.
E.g.: Vision 1: We are sure the solution makes sense
- Goal 1: Customers are interested in the product, SC: Based on VPD we successfully confirmed our hypothesis
- Goal 2: The product is cost-effective, SC: We have estimated revenues and costs
- Goal 3: The product is reliable, SC: Result of reliability test is more more than 80 %
- …
Expectations
Write down on sticky notes: “What am I most looking forward to during this week?”. It was evaluated at the end of the week as well as project visions and goals.
Examples:
- Work with sensors
- A new perspective on project organization
- I develop something to be proud of
- Mulled wine (= spend an evening with the whole team and mulled wine)
- Data analysis
- …
Product Backlog and Basic Architecture
We defined tasks which should be done during the week. Number of sticky notes was about 40, so we decided there is no need for a hierarchy. Grooming (Backlog Refinement) was a part of the meeting. You can read more about backlog definition and other preparation in the text below.
Name of the Product
A cool product needs a cool name! (And we needed to know how to entitle repositories…)
During the Week
On Tuesday we met up on stand-up, assigned own tasks and got to work. Subsequently, the rest of the whole week went just according to the plan as we set out to at the beginning of the run (as I mentioned in the previous chapter).
Friday Retrospective
Although we worked in sprints, we did not have formal retrospectives for each of them. The official “retro” part was arranged at the end of hackathon and consisted of these “games”:
Expectations Evaluation
Expectations, that we defined the first day, everyone classified into four lines (4 — delivered the goods, 1 — did not meet expectations) and gave constructive feedback. As you can see in the picture the biggest problem was that we did not go on Christmas mulled wine together.
What Happened and Why
Five-dimension star contained the following corners:
- Learnings — takeaways which I carry to the future
- Teamwork — how individual members fit together
- Communication — communication of individuals, honesty, open mind, keeping promises
- Organization — planning and prioritization of tasks, sprint alignment, backlog settings
- Result — how we are satisfied with the result
We followed the motto: “Let’s be strict on ourselves!” Everybody rated step by step the whole star on the scale 1–10 (1 — low score, 10 — high score) by giving feedback. We connected the lowest points and highlighted our success. The biggest mess was organization which we discussed deeper.
Visions and Goals Evaluation
The time has come to evaluate our initial visions. We compared the specified success criteria and up-to-date results. There is a possibility to measure the overall percentage of our success.
Summary
During and after the one of our best working week in the year, we caught several pieces of knowledge:
- Warning #2: the following information is very revolutionary: “Everything is about people.” However, only a great team can product great things and senior team members = there is no need for having lead roles or other role classification (except for a product owner). We have also confirmed that it is beneficial to engage somebody from business department in an IT project.
- 100% members time allocation is necessary.
- Physical board is absolutely sufficient.
- The optimal length of hackathon — one week.
- It is useful to have Stand-up, Sprint Review and Planning meeting every day. Retrospective meeting at the end of the hackathon event was well-timed because we were still focused on the project.
- Do not forget about business background of the product. During the week we e. g. interviewed many potential clients and investigated our hypothesis gained from VPD. It generated several other ideas and kept the team motivated during the whole week.
- Do not underestimate preparation. In our case we had these gaps and we could prepare more thoroughly in advance: scope definition, choice of technology, preparation of development environment (GitHub, cloud) or better choice of particular gadgets.
- Next things that are also not good to underestimate are vision and goals. Good goals and success criteria aim you through the whole project. Next time we will define them before the project kick-off.
- Backlog was a bit tough, too. Retrospective meetings showed us that we could plan more effectively because our expectations sometimes did not meet with the reality. So the lessons learned are deeper grooming and classification of task on Monday. And very important thing: do not forget to prioritize a backlog! E. g. using Pareto principle 20:80.
- Demo presentation was a significant part of the whole project.
- Our ending of hackathon missed a definition of next steps for the future continuation.
I hope you have well noticed from the text above how positive I feel about this experience. Within a week we did the work that would take months if not years in the standard corporate environment. We eliminated weekly status meetings and approval processes and thanks to this approach we minimized the project costs. The One Week Hackathon is a great shade of popular Agile methodologies and perfectly fits to confirmation of new ideas. Probably it could be useful for startups. In addition it is an excellent extension of the common work day.
