Product Clinic #7: It's a marathon, not a sprint

I’m Zaid, Lindus Health’s first software engineer. I joined Lindus to improve lives by transforming clinical trials using technology. As an early team member, I’ve been deeply involved in developing our engineering culture. Here I want to talk about how we balance speed and quality.

‍

One of the core values at Lindus Health is to “go fast”. It’s the belief that in anything we do,  there’s probably a way to do it quicker. This can ring alarm bells in engineers’ heads—visions of cutting corners, crunches, and careless code cross the mind. It’s possible that speeding up product development can be done by throwing more programming hours at it, but this tends to result in burnout, mistakes, and overall a poorer quality codebase. 

‍

One of the core values at Lindus Health is to “go fast”.

‍

Large companies invest a lot of money and effort in improving processes which enable engineers to write effective code, bringing in entire frameworks and hiring specialists to implement and maintain them throughout the organisation. These frameworks are often described as ways of working: the collaborative practices a product team undertakes to turn an idea into a valuable outcome.

‍

When Lindus Health’s product team consisted of a CTO, a product manager, and a software engineer, our process was very light-touch. We had an overarching goal, recorded the technical tasks required to deliver it, and took them on individually in a sort of Kanban-style. The only ceremonies in place were stand-ups and retrospectives, with some demos sprinkled in—then the team quickly grew.

‍

                                                                                                                 Basic task recording in Notion

‍

Agreeing on process

Suddenly we needed more organisation and oversight of what was going into the codebase. In our quality-driven industry where patient safety is the number one priority, it’s important that we agree on how we, as a product team, deliver well-tested and robust software.

‍

Do we fully formalise and pick one of the many flavours of Agile to follow? Do we keep it cowboy and risk the overlap of tasks and features, which could lead to them being implemented twice? “Neither”, was the consensus among us. Evaluating each of our (quite varied) experiences led to a great discussion on what we felt worked well for continuous delivery, and what felt like exercises in box-ticking, converging on an initial set of principles.

‍

It’s important to note that this framework is not considered set in stone: one of the biggest advantages of being a smaller product team is the ability to move quickly, adapt to change and improve. We reached our current way of working after some trial and error, and now we’re running at pace.

‍

One of the biggest advantages of being a smaller product team is the ability to move quickly, adapt to change and improve.

‍

Our way of working

I'm happy to say the process has remained light-touch, as we've favoured flexibility and autonomy over rigidity and surveillance. We've opted into what we believe to be the beneficial ceremonies of Agile, but eschew the idea of a "sprint". Instead, we delve into deeper “cycles” of feature development as, ultimately, each cohesive block of clinical trial delivery is complex and has a significant safety component; these need to be reasoned about fully in view of the bigger picture, which sprints struggle to accommodate.

‍

A short sprint can be a useful tool to focus work and iterate quickly, but we decided that they are not entirely appropriate for our end goals. We're still a small team, so dividing work into small enough chunks, estimating their story points, and ascertaining whether we have “enough” work in a sprint seemed like overkill. Instead, our cycle length is decided somewhat ad-hoc—releases can contain more or fewer coherent features depending on ever-evolving product requirements—but they are mostly between six to eight weeks. 

‍

A longer cycle gives time to meaningfully think about what is needed to be built. Engineers are able to avoid expedience which can come back around to bite us (and future developers), and in reality, validation in this space—both user and quality—can take longer than two weeks. The team is trusted to deliver what’s scoped for release without micromanagement resulting in less friction between a business need and code. We’re able to do more, advancing the product in multiple areas after shipping each cycle.

‍

The results so far have been some feature-packed releases and a real sense of agency among the engineers—we’re all invested in the “why” and the “what” so that we can best deliver the “how”.

‍

Zaid Al-Jubouri, Senior Software Engineer at Lindus Health