Why Retrium?

This past week, I told my boss at work I’d be quitting my job to be the co-founder of a startup, Retrium. Over the years, I’ve had plenty of ideas — some more successful than others — but I never quit my job to work on them. One might reasonably ask: why go “all in” on this one? In other words, what makes Retrium different from my past entrepreneurial endeavors?

Good question! Here are three reasons why I believe Retrium has a really great shot at becoming a very successful company:

1. Broader Market Forces

Retrium is a toolbox of facilitated retrospective techniques built specifically for distributed scrum teams. If you’re not in my target market, that might sound like a jumble of jargon, but it sits at the intersection of two powerful market forces:

  1. The increasing popularity of remote work and distributed teams
  2. The incredible adoption rate of agile and scrum within the software development community

Let’s start with the first one: the increasing popularity of remote work and distributed teams. According to ESNA, 20% of the global workforce telecommutes. More anecdotally, we’ve recently witnessed the incredible popularity of websites like Nomad List, which provides information about the “best cities to live and work remotely”. We also have lengthy crowdsourced lists of startups with a distributed workforce. In short, companies have begun to realize the importance of hiring the best talent, regardless of location. This trend is only going to continue as technology gets better and better at reducing the friction of a distributed workforce.

The second market force is the incredible adoption rate of agile and scrum within the software development community. The jury has decided, and agile has won. What began as a simple manifesto has turned into powerful force that is helping teams produce better software, faster. This is true, of course, for the startups of Silicon Valley, but it’s just as true for the multinational enterprises of New York and the nonprofits of Washington, D.C. After all, who wouldn’t want to be more agile?

Clearly, there are plenty of pain points left to solve in both of these relatively nascent markets. Retrium solves one of them.

2. External Hooks That Naturally Reduce Churn

The biggest challenge to the sustainability and profitability of any SaaS company is customer churn. The simplest definition of churn is “the rate at which customers cancel their subscription.” Why is churn so important? For each customer that cancels their subscription, a company has to find another just to maintain current revenue. If a startup wants to grow, then its customer acquisition rate has to be greater than its churn rate. Clearly, the higher the churn rate, the harder this is to accomplish.

One of the best ways to reduce churn is to have a high level of user engagement. After all, users who are engaged with your product are less likely to cancel. One of the things that excites me most about Retrium is the fact that it has a high likelihood of having extremely low customer churn.

Retrium benefits from something I call an “external user engagement hook,” which is something that encourages customers to use your product from outside the product itselfRetrium’s external user engagement hook is the scrum framework, which requires teams to run retrospectives on a regular — and frequent — basis. The hope is that every time a team needs to run a retrospective, it will be reminded to use Retrium. Having an external user engagement hook can be an incredibly powerful driver of low churn, and it makes me confident in Retrium not only as a product, but as a business as well.

3. I’m Passionate About It

One of the worst mistakes a founder can make is to start a company in a market that he or she is not passionate about. Popular culture would have you believe that founding a startup will lead to a glamorous life full of parties and ritz. The reality is quite the opposite — startup life means hard work — really hard work. As a result, founders of startups can burnout quickly, especially those who start companies in markets they aren’t personally passionate about.

As for Retrium, I’m fortunate that it’s at the intersection of two areas I’m truly interested in: agile software development and distributed teams. In fact, Retrium itself is being built with these concepts at its core. Not only are we using the scrum framework to develop Retrium’s code, but we’re also a fully distributed workforce (we have no office).

Looking Forward

None of this means that Retrium will, in fact, be successful. Most startups fail, and it’s far too easy to live in a positive echo chamber that can lead to overconfidence in your idea. Nonetheless, I truly believe the future for Retrium is bright. I’m excited to get going.

Coming soon: a post describing how I got the confidence to quit my job and start Retrium. I’ll give you a hint: Lean Startup.

Excited to announce Retrium — distributed retrospectives made easy

For the past few months, I’ve been hard at work in my spare time on a startup in the agile/scrum space. Along with my co-founder, Ryan Detweiler, I am very excited to reveal it to the world (or, at least to those select few who actually read this blog!). It’s called Retrium — and it’s a tool that makes sprint retrospectives easy and effective for distributed scrum teams.

header

Here’s why we’re building it. If you’ve ever worked on a team that uses the scrum framework, then you probably know all about sprint retrospectives. Most likely, you’ve been exposed to retrospective facilitation techniques like 4Ls, Lean Coffee, The Wheel, or Mad/Sad/Glad (no? you should try them!). Here’s the problem: all of these techniques require flipcharts, sticky notes, markers, and other physical tools. While that’s fine and dandy for collocated teams, geographically distributed teams are left out in the cold. That’s where Retrium comes in. We want to bring the power of these retrospective techniques to distributed teams.

Here’s what it is. Retrium is a set of super-simple interfaces to some of the most popular retrospective techniques. It is completely device independent, so you can use your phone, tablet, or desktop to participate. Retrium is also a facilitator that guides you through the retrospective itself. Don’t know how to run Lean Coffee? Don’t worry, Retrium takes care of that for you. Finally, Retrium doesn’t try to do too much. It isn’t intended to replace video conferencing, it merely complements it. In fact, we recommend you run a video conference while you run a Retrium-powered retrospective.

Here’s our timeline. We are aiming to launch our MVP in the summer. In the meantime, in good lean startup fashion, we have a pretty landing page with a place to enter your email if you’re interested in hearing more.

So that’s it. If this resonates with you, reach out and get in touch! Please email me so we can schedule a time to chat.

Retrium — retrospectives made easy.

Should the Product Owner be included in a sprint retrospective?

I came across this question on Quora recently and couldn’t help but respond, as its a question I deal with pretty regularly. Here is my answer:

Why shouldn’t the product owner be included in a sprint retrospective?

TL;DR: Sometimes its a good idea to invite the PO and sometimes its not. It’s the Scrum Master’s responsibility to invite the right people to the retrospective each time, based on the team’s current impediments.

Long Version: There is no hard and fast rule on who to invite to the retrospective. The right answer will almost certainly change on a retrospective-by-retrospective basis. The right answer also depends on many things:

  1. The relationship between the PO and the team
  2. The relationship between stakeholders and the PO
  3. The relationship between your manager and your team
  4. The current issues that the team faces (are they more technical or more business-oriented?)
  5. And any number of other potential things (sorry to be vague…)

As the facilitator of the Retrospective, it is up to your Scrum Master to structure the Retrospective such that it will lead to continuous improvement. If that means involving key stakeholders, then those stakeholders should be invited. If that means a closed door session for just the core team, then the retrospective should be closed to external participants.

Since Scrum Masters have no hard power, a good Scrum Master would understand the need to seek input from the team, the manager, the PO, and relevant stakeholders in order to build consensus on who to invite each time. A good Scrum Master would build a positive relationship with your manager such that the manager will eventually understand why this flexibility is so important.

Scrum Masters, what do you think? Do you agree that the best answer is it depends?

10 Things A Good Scrum Master Never Says

A7725B3C2F

 

Good Scrum Masters are almost always busy. Yet, plenty of articles wonder what a Scrum Master does all day. In response, here are 10 Things A Good Scrum Master Never Says:

 

#1 I have nothing to do today because my team isn’t facing any impediments!

#2 The product backlog is in such good shape that we don’t need to look at it anymore this sprint.

#3  I wish we had at least another page of documentation on that requirement. It would help clarify what our stakeholders want.

#4 Our meetings don’t start or end on time, but I can’t change that because it’s part of company culture.

#5 I know everything about scrum, so there’s no need for me to attend scrum-related meetups, classes, or conferences anymore.

#6 If only I had more hard power. Then I could affect real change.

#7 I’m so bored of our daily scrum meetings that I always find myself spacing out! I wish we could just skip them once in a while.

#8 Everyone in my company is on board with this agile thing. There’s no need for me to take them to coffee to get to know them a bit more.

#9 Our retrospectives are so useful that I don’t need to research any new facilitation techniques.

And lastly…drum roll please…

#10 I wish we could go back to the waterfall model. At least we had clarity on what we were trying to build.

Perhaps this list of “quotes” will give the doubters a sense of how complex the Scrum Master role really is, and how few people really have the skills to do it right.

Any other quotes you’d like to add to this list? Feel free to comment below.