Aragon Core v0.5.1 Post Mortem — Part 1

Aragon -

Summary of our first new development cycle

Background

I joined Aragon in late February 2018. Developing a structured product management process is one of my main responsibilities. 0.5.1 was our first sprint attempt since I joined. This sprint concluded on 31 May 2018 with our Mainnet Survey app release.

Our initial goal is to establish three two-week sprints. These sprints define a six week cycle. We established this goal as a starting point for the new product development process. The goal emerged from a discussion at our last offsite meeting in Switzerland. 0.5.1 started immediately after the offsite, on 16 April 2018.

A guiding principle of the new process is to define one that's balanced between -

  • Being beneficial and
  • Maintaining space for, i.e. not stifling, creativity and innovation

Being beneficial means -

  • Establishing predictability
  • Optimizing resource efficiency
  • Optimizing alignment between what we build with what the community needs
  • Supporting and improving the team's wellbeing

The latter is of particular importance to us at Aragon. It's not something we like to say or pay lip service to.

Establishing a sustainable product development process is a top priority for us. It's actually one of the main factors that convinced me to work at Aragon. Company work styles like those of Doist and Basecamp influence much of the work I do.

It's also critical for the process to not become too restrictive, as the space is new and changing fast. We want to keep up with and lead this change. An overly restrictive process for the sake of process could easily kill-off creativity and stifle innovation. None of us want to see that happen!

0.5.1 started on 16 April 2018 the intention was for it to last two weeks. After that 0.5.2 would begin. A two week testing and fixing cycle would follow 0.5.2. These three two-week sprint would comprise our first six week cycle.

Expectations

A process rarely, if ever, is either implemented or works as intended the first time around. I've learned an initial process implementation can be a very frustrating experience.

Yet, the frustration often arises from misaligned expectations. The expectations are that the process will get everything just right the first time.

Instead, I've learned the initial process implementation won't fix everything, right away. It's not supposed to. It's more beneficial to view the initial process implementation as a guide.

The initial process implementation is also the first step along a longer path. It's the first step toward learning -

  • What works and what doesn't
  • The nature of a team's strengths and weaknesses
  • And to a lesser extent, how long things REALLY take to do :)

That said, it's important to start somewhere. Taking the first step is often delayed or even prevented by a desire to get things just right.

So the initial process implementation is the first step in an evolving process, rather than the perfect end-state. Understanding this releases a team from a paralysis state. It allows the team to take that first step.

So the intent of this first sprint was to take the first step. We hoped it would provide some immediate benefit. At the same time, we viewed it as the first step along an evolving path. It's with these expectations we initiated Sprint 0.5.1.

Stay tuned for part 2 of this post. In part two I'll discuss outcomes and the valuable lessons we learned.