echtzeit.dev services

Solid
Engineering
Solutions

Since 2016 we worked on a multitude of compiler and tools projects with companies from different industries. The invariant observation is that projects are all very different. There is no way to know in advance what the dominating complexity will be next time. Our answer to it is an approach that we call Sprints and Breaks.

Nice to e-meet you!

When a client reaches out, we usually ask to arrange a 30 to 60 minutes intro call. In order to be effective, a technically versed person from the client side must attend the meeting. In part 1 we introduce each other and our roles and responsibilities. The goal of part 2 is to answer a number of questions essential for planning the first sprint. The below check-lists may give some inspirition. The more of these questions we can answer the better we can plan the first sprint.

Check-list Bugs

Do we know what exactly the problem is?
Can we reproduce the problem in a deterministic way?
Are there any workarounds that we know about?
Can we identify the part of the code base that causes the problem?
Can we break down the problem and define a first step?
Can we make an effort estimation for the first step?
Or otherwise: How long do we think it takes to understand the problem good enough to estimate the first step?

Check-list Features

Do we know what exactly the goal is?
Can we write a test that covers the feature?
Is there a way to emulate the functionality without code modifications?
Can we identify the parts of the code base that need to be extended?
Can we break down the feature and define a first step?
Can we make an effort estimation for the first step?
Or otherwise: How long do we think it takes to understand the context good enough to estimate the first step?

Sprints and Breaks

Structuring efforts is one of the fundamental requirements when working on high complexity tasks. We rarely know in advance what causes a problem on the implementation level or what it takes to fix it. We have to start with estimations. And if we don't have enough understanding to make an estimation, then we take one step back and try to estimate how long it will take to gain this understanding.
This leads to the concept of sprints: A sprint is a time-boxed block of work that aims to complete a well-specified task. On the executive level, it might be a feature implementation in a code base. On the preparatory level, it might as well be about finding answers to a given number of questions. Once we know the answers, we revisit our planning and decide what the next step would be. If we didn't manage to complete the sprint within the time limit, it's a signal to revisit the previous planning.
Making good decisions under uncertainty is never easy and must not be hurried. Having breaks between sprints allows all participants to evaluate results, revisit their relevance for the overall project goals and prepare their inputs for the next sprint. Breaks improve the quality of our next planning.
Time-boxed breaks are a matter of efficiency. There's this common practice for meetings: The more people attend, the more we must prepare and focus our own attendence. That's because time is precious and it is hardly acceptable to waste other people's time casually on a scale. For the same reason we should allow for fixed breaks between sprints. Clients often work on many different parts of their products concurrently. Naturally, review and planning don't score their deserved priorities in the battle for engineering time. Giving clients enough time to schedule such tasks is key for decent feedback and that's what breaks are all about.
In our experience, Sprints and Breaks is the best way to approach new projects in a time-efficient and plannable manner. That said, we will always be open to hear your take on the topic!

Sprint One

In our experience there are more questions than hands-on tasks in the beginning of a project. The first sprint is usually packed with research and two weeks is a good time-frame to understand the issue and prepare input for planning the next steps. In order to make sure our understanding of the problem matches yours, we will have a lot of questions as well. Thus, a technically versed person from the client side must be reachable during the first sprint — anything like Slack, Discord or E-Mail is fine.
Sometimes issues turn out to be simple, e.g. if we investigate a bug and we find a workaround that is "good enough" for the client's purposes. In such cases projects can be finished within a single sprint!

Break One

For the sprint review meeting we send over a decision diagram to help the client decide on the way forward. Once all questions are answered the client can use the break time for internal evaluations and decision making in preparation for the next sprint.
In our experienced two weeks is a good time-frame for the first break. That said, there are always cases where clients are in a hurry or a technical expert is out-of-office. We are always eager to vary the two-weeks pattern and meet your demands.

Repeat

The sequence of Sprints and Breaks repeats until the project is done. Over time less and less client feedback is necessary and so sprints can get longer. This can be the case once larger implementation efforts are required while goals, requirements and design already became clear.