How we built Kontist - Tax Service in a "Week Sprint"?!

Problem

Berlin is full of FinTech companies that fight for users with USPs of all kinds of USPs. Several years ago it was banking in your pocket. Then each bank got a mobile app and FinTechs have focused on trading, smart insurance, or bitcoin accounts. I joined Kontist with one mission: to link banking and tax operations so that users don't think of the tax hassle at all, knowing that the tax side of the business is been taken care of.

If you live in Germany you probably know those words: Steuern (taxes), Finanzamt (financial authority), and Umsatzsteuervoranmeldung (VAT Advance). They all have a strong negative connotation. The foundations for the modern German tax system were laid one hundred years ago. From July 1919 to March 1920, the Erzberger fiscal reform was implemented in an unprecedented effort, significantly driven by Matthias Erzberger, the Reich Minister of Finance at the time. Every change or update to the system only adds complexity for the taxpayers.

Just compare German VAT Law. 100 Pages vs 18 Pages of VAT Law in Estonia.

There is a simple explanation of the route of the problem. German tax authorities can't just update an entire engine and keep on adding modules on top. So regardless on change or update in your tax history one simply sends the whole declaration one more time. So if you do your own taxes and use Elster (In fact that's the only way possible) you can't simply update part of your tax declaration. You must send it all over again and override the last version.

Speaking in technical terms: they don't just update the part of the code that has a newer version. They update and render the whole page. (We are talking about times before even AJAX was introduced).

The whole industry of TAX Advisors appears to maintain the tax collection system. For most German Freelancers or Entrepreneurs having a good TAX advisor is almost essential with success in running a successful business. Even if the relationship with your tax advisor is not particularly good, most people are afraid of not finding a better alternative.

So exactly this was the challenge we decided to tackle.

Any attempt to revolutionize this industry sounds extremely difficult. You deal with the outdated and rigid tax system and even more rigid software that was first designed in 1996 with constantly added functionality. (Elster).

Any startup trying to jump into this space should first access technical due diligence in writing C-based wrapper to build any front-end system. ( C-Schnittstellenbibliothek (?ERiC“ = Elster Rich Client, formerly ?TeleModul“). The current documents are only available in German.

So as every startup #Kontist has a spirit of embracing complexity and turning the wheels toward the benefits of our users.

We listened to our clients. Most of them hated dealing with taxes and tax advisors were not happy working with freelancers either.

Solution

Our users use Kontist primarily for business, so we have their data in real-time. Why not build a pipeline that automatically helps in terms of bookkeeping and delivers user data in ready to file form?

Just imagine! You are using a banking mobile app. Each time you pay or receive the money you are prompted to take a photo of your receipt/invoice. We sort your transaction into proper Elster categories (accounting). So your Tax advisor gets to see already prepared, accurately categorized data that he could forward to Finanzamt with only one click. And with no human interaction involved, we have no human error risks that are normally associated with manual accounting.

We ran a few user development tests and the results were astonishing. The potential user waiting list was bigger than any other feature we have planned at Kontist.

Time constraints

The"best" part of this story is the timeline. We only had 3 months to get the product on the market. Those of you who build the software for a living know the drill: Concept Validation - Desing Spring-Development - Learnings- Adjustment-Scaling.

Obviously this would not work with 3 months to the deadline with "0.00" in our backlog. Yes, we did not even have a name for a project. It was literally starting from scratch.

One Week Sprint

We've spent a few nights thinking about the best approach to making this project successful. And "One week sprint" is a result that sounded crazy at first but turned out to be a highly effective methodology for ambitious goals.

Our Engineering Team was working in Kanban mode (no sprint). So any shift towards sprints was a risky step. Having one week sprint was a red flag even form the concept perspective. But we have tweaked the concept to keep high velocity and "zero stress" policy. How?

We started each Monday with a "Tech. Planning", where Backlog was already pre-filled by me. And Developers were pulling the tickets in the Planning/Sprint column. Pulling only that amount of work (tickets) that is feasible to finish in a week. This way we made sure that pulling less means more in terms of Sprint Delivery. Each Friday we were doing an internal demo (staging) where we've tested each feature to finish&close the sprint. Once the test was done we were deploying this to production and recording video walk-through (https://www.loom.com/) would be sent to our Business Unit. This video link would show new features (already live). Businesses were loving us! Each week a new set of features already live...

Our Business - Tax Ops (Accounting Team) was using excel or Google worksheets tools at the beginning and each week we were automating some of their work into a web app. Each Friday the LIVE product was growing with a number of features we shipped. Over the weekend I had to collect the feedback and was preparing a backlog for the next Monday. We went 9 weeks long in this cross-fit tempo.

I was a bit afraid of not keeping the pace. After the 4th sprint, we had a RETRO session where most of the developers have shared their feedback. Most engineers actually liked the way we go and agreed to keep it going until the release. Uff... It was a big relief for me.

So today we are proud to announce the first market-ready Kontist Steuerservice that brings a new KPI in the engineering world. TAX SUBMISSION LEAD TIME :)

What have we learned from the "1 WEEK SPRINT"

Advantages:

1. The biggest advantage was little stress-level related to planning since most of the backlog was already prioritized over the weekend based on feedback from the business unit.

2. People could start the weekend without carrying the problem over. One could have peace of mind over the weekend and a fresh start on Monday.

3. Easy estimation. No shots in the dark. Simply take the tasks you are able to finish in one week.

4. Weekly releases allowed us to constantly push the new features and have extremely short learning loops. Instead of 2 weeks in a classical sprint we shortened the time to 50%. (About 50% of new features were based on the direct feedback from our hard-working Tax Ops.)

5. It gave the team a morale boost as they were building the product in small iterations incredibly fast and had 100% delivery on time.

5. Perfect for Microservice architecture. Each Tactical Unit was working in the different repo that allowed higher development agility and reduced delivery risks. (User On-boarding, VAT Calculation, Auto-categorisation, TaxOps Interface etc.)

Challenges:

1. Your product team. In this project, it was me who had to work on the weekend, testing the working product version and building a product backlog for the upcoming Monday. 3 months are totally doable but one might need a strong determination to keep it up for longer. IMHO "1 Week Sprint" is the perfect methodology for a short and intensive project that could give you an unfair competitive advantage by being fast on the market or building a product for a specific legally binding date.
2. Your technical team (squad) has to be split into tactical units. Instead of one squad, we started to work with 3 technical units (2 Engineers each). You can be surprised but making a decision in a team of 3 is much harder than a team of 2.
3. Team commitment. You need to have a well-balanced team where each member is equally committed to the goal. It was done by organizing a value workshop where the product vision was pitched to the whole team. Then, we had to mark how confident you are in finishing this product on time (3 months). Anywhere above 80% is a good result ( We had about 80% confidence).
4. Ambiguity and High Load. Texas is a seasonal business. In Germany, all VAT declarations must be prepared and submitted before the 10th of each month. But most of the transactions booked in the bank account on the 29-30th of the month. So you have 10 days of high pace work to categorize and prepare all transactions. With manual processes at the beginning, it was a hell of a job for the whole team. Try to automate everything you do manually as you go. Planning the whole process upfront will not work.
5. Manual work is the biggest source of accounting errors. One "coma" in the wrong place might create chaos on your tax report. Try to eliminate human entry as early as possible. Try bringing a new set of automation each sprint.
6. Try to eliminate most of the errors at the data source. Make sure you run all systems at the same time zone set. A difference of 1h would give you a few more transactions at the end of the month which would break your whole calculation if it’s not synced. Reduce the number of entry options for your team. We started building different filters with different options for each data filter right at the beginning. Make your front end a data gatekeeper.
7. Have FUN! Taxes are by far the most boring business for the software team. Little rituals and celebrations each week will bring some bright colors to the grey world of taxes.