Establishing Baselines: The Key to Sustainable Development

Why we should talk more about establishing baselines.

In the world of software development, we're always chasing the next big thing. Whether it's a new feature, a cutting-edge tool, or the latest agile methodology that promises to solve all our perceived productivity problems. But as we figuratively sprint from one goal to the next, I believe it's easy to lose sight of one crucial concept that underpins long-term success: Establishing and Maintaining Baselines.

So what do I mean by this? Let me explain.

The Problem with Sprint Goals

Sprint goals are the lifeblood of agile development. They aim to give teams focus, provide a sense of accomplishment, and push us to deliver (hopefully meaningful) value in a short amount of time. But here's the catch: sprint goals are inherently forward-looking. User stories describe a form of reality that is not yet realized. They focus on what we want to achieve next, not on where we currently stand. This forward-only focus can sometimes lead us into dangerous territory.

Let's build a house.

Sprint goals are like the blueprints for each room (setting aside the notion that blueprints inherently possess a degree of specificity, which might not be necessarily the case for sprint goals). But what happens if, in your rush to complete the kitchen, you forget to ensure the foundation is solid? Or worse, what if every time you add a room, the structure as a whole becomes a little less stable? Hello, Tech Debts! You're technically reaching your sprint target. The kitchen has been built, all user stories describing different ways one how someone would want to cook spaghetti have been delivered. However, your baseline has deteriorated. Now, it would be foolish to believe that this possibility is not known to project managers. Though, if you ask them, they will tell you that it is implicitly understood by everyone involved. But this is where the problem lies. In the "Zen of Python" it states that explicit is better than implicit, and I believe this idea can be applied here. So let's be explicit and talk about baselines.

What Are Baselines, and Why Do They Matter?

A baseline in software development is a set of metrics or conditions that define the minimum acceptable state of the system. It’s the foundation that should never be compromised. Think of it as the lowest acceptable point of quality, performance, security, or usability that your software can dip to. Once established, a baseline ensures that every iteration, every sprint, every deployment, every merge doesn't just push forward but also maintains the system’s existing state. If sprint goals are about "what's next," baselines are about "how far we've come and what we can't afford to lose." Sustainable long-term development is just shifting this baseline forward. Centimeter by centimeter or inch by inch. Agile methodologies, for all their strengths, can corner themselves into situations where they often gloss over the importance of establishing and maintaining these baselines. The focus is squarely on velocity and delivering new features. There’s less (explicit/communicated) emphasis on ensuring that these new features don't degrade the system's existing performance, reliability, or security.

Sure, Agile talks about "Definition of Done" and "Acceptance Criteria," but these are often tied to specific stories or sprints. What’s missing is a commitment to ensuring that every sprint also preserves or enhances the overall baselines of the system.

Shifting Baselines: A Sustainable Approach

To develop software sustainably, I think one needs to adopt this shifting baseline idea and use it during general communication and planning. This means that with each iteration, we not only focus on adding new features but also on raising or, if necessary, maintaining the baseline itself. Each sprint should involve not just delivering new value but also evaluating the impact on the existing system and ensuring that our foundation remains solid. Unit tests are a great example of such a baseline. You would never merge code that causes 5% of tests to fail. Because it's compromising your existing baseline and baselines should never be sacrificed for the sake of a new sprint goal. A more subtle baseline could be the UX of a specific feature workflow. Or my favorite: a very naive implementation of a solution. Because these baselines can also exist on code level. We all found ourselves in a situation where we knew how to solve something but still pondered for hours on how to solve it in a "more efficient", "more maintainable" way. Go into GSD-mode (Get Shit Done) and implement the naive solution. Sure, it might not be the most performant one, but you have established a small baseline. Your system works, and it will not become worse than it currently is.

Communicating the Importance of Baselines

Baselines do not provide a new way of doing the same things differently. They are not an alternative to existing processes. They are a way of communicating something in a more explicit way. Because one of the reasons they often get overlooked is that they aren’t always clearly communicated or understood. It’s crucial for product managers, developers, and stakeholders to all be on the same page about what baselines exist in their current product and why they matter. In some way, they can be understood as MvP definitions adjusting with time. Evaluate potential changes against the current baseline. If there is none, create one! Before implementing all these fancy features for the future, make sure that you have a baseline to compare them against. Think back to the naive solution example I provided earlier.

Conclusion: Building for the Long Term

In the rush to deliver new features and meet sprint goals, it’s easy to forget the importance of establishing and maintaining baselines. But without solid baselines, our products are at risk of becoming unstable and ultimately unsustainable.

So, the next time we are in a sprint planning or solving a different problem, we should take a moment to ask ourselves: What are our baselines? Are we maintaining them? And how can we shift them upwards as we move forward? Because in the end, sustainable development isn’t just about reaching the finish line. It’s about ensuring that the road behind you doesn’t crumble as you move ahead.