The quintessential rite of passage
The endless Interstitial Sea
Beyond death, yet before life
Trivial to comprehend, yet momentous to overcome

Time had come for Aristotle. He found himself on the Interstitial Sea.

He vowed not to be one of those aimless souls that had been spoken of. Souls who wander aeons across the Interstitial Sea. Averse to arrive. Consumed by wanderlust. Not lost to the sea, yet lost to themselves.

It would go differently for him. He was determined.

Yet it would prove not simple for Aristotle.

His craft was a sturdy one, made of strong yet supple wood that responded well to the changing forces of the sea. The mast was tall and straight, its sails eagerly danced to capture the wavering winds. As with all who traverse the Interstitial Sea, he travelled alone. Yet he took solace in having prepared well for this journey. His craft took a lifetime to build, and it served him well now. …

Intuition in software engineering only gets us so far. We can develop reliable intuitions around software architecture design, root causes of bugs, and even user experience issues. However, estimates often betray our intuition. We tend to under-estimate effort more often than we over-estimate it. Even backlog items with the most meticulously-researched requirements are vulnerable to delays once coding begins. What happens then if we go against our intuitions when developing our software estimation practices?

When asked for an estimate, our first intuition is to respond with a time duration. This article explores an alternative: story point estimation. I will shed light on its origins and how the practice has evolved over two decades. …

In my previous article, I covered three principles that help ensure a product team uses software estimation effectively:

1. Estimation Value: “We understand the value of estimates to us.”
2. Estimation Autonomy: “We decide on how we estimate.”
3. Estimation Ownership: “We all own the estimates.”

Each of the three principles supports the other two. A team that skips over the estimation value principle subsequently fails to agree on the software estimation process, refuses to take responsibility for it, and may ultimately abandon the practice altogether.

At the heart of estimation value are the reasons product teams estimate software development work. …

The topic of software estimation tends to be an unavoidable one for product teams. It is often a source of contention, as every team member brings distinct experiences and opinions on the topic. While there is much disagreement, a common shared experience is that underestimation is more common than overestimation. This tends to create an undertone of cynicism towards software estimation.

This mindset towards software estimation underscores the importance of exploring the topic. When applied effectively, software estimation is a powerful tool that can help teams select, prioritize, and implement software changes optimally and reliably.

When teams fail to intentionally broach this often-uncomfortable topic, it’s discussed at inopportune times — while the team is stressed, under pressure, and in a reactive mindset. This leads to an outpouring of…

In my last blog post, I introduced a set of tools that help self-managed teams communicate and collaborate effectively. These tools are known as the Core Protocols. I also suggested that Core Protocols and mindfulness are connected. By adopting the Core Protocols, an organization can create fertile ground for mindfulness to flourish. Furthermore, mindfulness can act as a catalyst that makes Core Protocols more effective in their application.

Introducing Core Commitments

All of the Core Protocols either explicitly or implicitly require the Core Commitments as a prerequisite. The Core Commitments establish a consistent mindset and behaviour for the team, which in turn creates a sense of security and trust that provides the appropriate environment for earnestly adopting the Core Protocols. …

Autonomy, Core Protocols, and Mindfulness

I work at Nulogy, where Autonomy is one of our core values. Consequently, there is a strong drive towards growing both self-managed and self-organized (also known as “self-governing”) teams. (If you’re wondering what the differences between these two types of teams are, this article delves into details.)

For a company to sincerely embrace the effort of building such teams, many activities must be done differently — sometimes unconventionally. One of these activities are meetings.

Meetings: An Incompatible Approach

Before I started at Nulogy, I had a certain expectation of how meetings should happen.

To illustrate:
- The meeting organizer brings an agenda.
- Runs through it.
- Concludes the meeting by distributing action items to attendees. …