This is an interview with Small Improvement’s software developer Laura Sochaczewski about how the development team works together, how sprints are organized, and how developers stay connected with customers. If you want to read on, you find another developer interview here.

Hey Laura! You joined Small Improvements as software developer in 2019. Can you tell us a little bit about your professional background?

After studying business and economics, I worked for a few software companies, doing both product management and software development. I especially enjoyed the programming part, so in 2019 I took a break and went to a coding school for half a year, to dive deeper into web technologies. After that, I joined Small Improvements as junior developer. My main task here is programming, but I’m also involved in product discussions and feature design. I really like this combination, because I get to see the impact of my work directly, and it feels very “holistic”.

What parts of the Small Improvements app do you work on?

When I started, I mainly worked on the frontend, because I was most familiar with frontend technologies back then. Nowadays I also write Java code for our backend, or participate in deployments. One thing that I really enjoy about my job at SI is that everyone has the ability to contribute to all parts of the app. For example, there is no strict split between backend and frontend developers. That way, there is always something new to learn and discover. This really helped me to develop my skills and gain more experience.

What’s your typical work day like?

I don’t really have a typical routine, although broadly speaking I spend most of my time working on software. For example, I write code for a new feature that we are about to ship; or I review a pull request from one of my colleagues; or I refactor something to improve the code quality or performance. We also have some meetings of course, but that’s within reasonable limits. All in all, I feel that there is a refreshing variety of tasks, so it never gets boring.

Do you have fixed working hours?

We have flexible work times, so some developers prefer to start early, whereas others like to get up a bit later. One thing that’s set for all of us is our daily standup meeting that we do midmorning, where everyone briefly shares what they are busy with. That helps us to know what’s going on in the team, or if someone needs something. I mostly work from home these days, so the standup meetings are an important factor for me to stay in touch with the team.

Is the entire development team working remotely?

It’s mixed: although all of us developers are currently living in Berlin, some people prefer to mainly work from home, like me, while others go to our office regularly. We have a pretty cozy office in the center of the city, which has some work stations that all of us can use. But that’s more of an offer, everyone is free to decide what works best for them.

How do you communicate with each other?

Our “watercooler” for communication is Slack. But we also regularly hop on calls via Zoom to discuss questions or to do pair programming sessions. So even when I work  fully remotely, I still feel connected to others. It’s also possible for us to meet at the office, where we can work side by side, or gather around the table to put our heads together.

The development team at Small Improvements consists of 5 people currently. Do you enjoy working in such a “small” setup?

Yes, definitely. I think one benefit is that everyone is involved in all parts of the tech stack. Even if you have a certain technical focus or preference, this broadens your horizon and gives room for you to grow professionally. The other good thing is that the communication between us feels very direct and effective. If you need help from someone, or if you want to get a second opinion on something, you just reach out to people directly. This is not just true for the dev team, but for the entire company. I generally feel that the process overhead is quite small here.

Does the team size also have challenges?

It sometimes can be tricky when multiple people take time off at the same time. The company generally wants people to stay flexible in regards to their vacation, so that requires good coordination. For example, when multiple developers are on leave, we avoid releasing bigger or more complex features, to mitigate the risks.

You mentioned a “small process overhead” earlier. Can you describe how the dev team organizes itself?

Our work process is based on Scrum. We work in 4-week sprints, which we plan together in a kick-off meeting. Our product manager maintains a feature roadmap that we pick from, and in addition to that we also schedule refactorings or other technical work that we deem necessary. Every sprint is concluded by a retrospective, in which we discuss what went well and what we can improve. The sprint structure makes for a good structure and rhythm, but we remain open to enhance our processes and make changes to them if we feel it’s necessary. Since the development team works fairly autonomously, the sprints are also a good way for the rest of the company to see what’s in the pipeline right now.

What tools do you use for planning the sprint?

Our sprint organization and near-term roadmap fits into a single Trello board. We don’t really have a need for more sophisticated tools at the moment, and this simplicity helps us to keep our process lightweight and it encourages direct communication. That style of collaboration requires some discipline and initiative from everyone, but it allows us to stay flexible and efficient.

How do you collaborate with the product manager and the other stakeholders?

Our product manager helps us to prepare our sprints, and we regularly discuss the current status quo with her while we work on tasks. When building new features, not all requirements or implications might be clear right away, so we often have to figure things out iteratively. Last year, for example, I collaborated on the overhaul of our app’s navigation. The number of features and functionality started to outgrow our previous navigation, so we wanted to redo it. Two of us developers, our product manager, and someone from the customer support team worked out how to implement a new approach to structure things in a better way. We also asked a few customers for thoughts, and factored in their feedback.

Do you get a lot of feedback from your customers?

We are in the lucky position that some of our customers are very eager to give us feedback and help us improve our app. That’s especially useful when we develop new features. Sometimes, the customer support team arranges a video call with a customer, where one or two of us developers join in as well. We then discuss design drafts or potential workflows with them, and they tell us what they think. This is a super valuable resource for our research, because we get direct insight into the needs of our end-users. In addition to that, it’s also personally rewarding to maintain such a close relationship with the people who use our tool.

You are part of the design team. What is the responsibility of that team?

The design team is like a “guild” whose responsibility it is to ensure the quality and consistency of the user experience of our app. Including myself, there are currently 4 people in the design team: one other software developer, who is also passionate about design and UX, our product manager, and a freelance designer who supports us. We also keep an eye on our style guide, which is an internal ReactJS component library. It contains a large variety of building blocks and usability patterns that our frontend consists of. We have built up and maintained that style guide over the course of many years now, and it proved to be a big productivity enabler for us.

Thank you, Laura, for giving us an insight into your work!

If you want to learn more about the development team, you find another developer interview here.