Fast Feedback Loops are Vital for Managing a Remote Team

Managing a remote team is different than managing a team with everyone in the same office. This article is about feedback loops in remote teams.

With feedback loop we mean the kind that spans from starting development of a new feature until a product owner is using the first version of the feature to give the developer feedback.

Managing a remote team, no matter how remote.
Managing a remote team, no matter how remote. (Photo by Julius Drost on Unsplash)

When the team is in one room the developer can just ask the product owner any time: "Should the feature behave like this? (pointing to her screen)" The product owner can come over and test the feature. In a remote team it is not so easy. Of course you can share your screen and present the feature, but it is way better for the product owner to use the feature herself to see if it works and feels right.

Long Feedback Loops are bad

In a remote team in order for the developer to get feedback from the product owner, she needs to have the feature she is working on running on an URL that is accessible for the product owner.

Most teams have a staging environment for this. But if the team is bigger than three or four developers this single staging environment can become a bottle neck pretty quickly. It can happen, that one developer needs to wait for the staging environment to be free to deploy her new feature to it so the product owner can review it. This can take sometimes a couple of days. During this time of waiting for the staging environment the developer starts working on something else. If the review of the new features arrives she has to switch her brain back to that feature. This switching back and forth between features costs a lot of time and energy. In general, the faster the feedback loops the less context switching.

Additionally long feedback loops lead to not detecting problems early on, which wastes time and money.

Short Feedback Loops are Super

So now we know that the feedback loops should be as fast as possible. The ideal situation would be:

  • The developer works on a new feature.
  • When there is a question during development she has a link to the version she is currently working on at hand.
  • She can send the link to the product owner on Slack and asks her for feedback.
  • The product owner opens the link, has the current state of the feature running and can give feedback immediately.
  • Wouldn't that be nice?

    On a side note: Short feedback loops also lay the foundation for continuous improvement.

    Make it Easy for Your Developers to Show Progress and Request Feedback

    If you use one of the new fancy serverless frameworks you basically get a running system for every commit. Really nice! But what about the other 99% of all software projects in the world? The grown software projects that have been started years ago when there was no serverless?

    Stage 1: One Staging Environment

    Smaller teams probably have one staging environment that is accessible from the internet. If the team grows this one staging can get a bottle neck quite fast. This can happen: One new feature is on staging and another one has to wait until the first feature is reviewed so it can be deployed.

    Stage 2: Multiple Preview Environments

    If this one staging environment is not enough anymore the team creates a second or maybe third environment called dev or preview by hand. These environments take some time to be implemented and need to be maintained.

    If those two or three preview environments are not enough anymore the team probably wants to have infinite preview environments that can be started and stopped as needed. Lets call this continuous previews.

    Stage 3: Continuous Previews (Dynamic Preview Environments)

    This is when the team starts to create a system where they can spin up preview environments on demand. Either they

  • have someone on their team that knows Kubernetes,
  • they build something by hand with shell scripts or
  • they hire a DevOps consultancy to build this continuous previews system for them.
  • Either way, this again consumes a lot of time and resources to initially implement and later to maintain and extend. An because there are almost always more important features to build, most of the times it ends like this:

    Building your own system can be a huge money sink.
    Building your own system can be a huge money sink. (Image by XKCD: https://xkcd.com/1319/)

    Shameless Self Promotion

    Chances are high that building a continuous preview environment like described above will consume a lot of your teams budget and time. Time your engineers could spent building actually cool stuff.

    We built WunderPreview to fix this issue. WunderPreview gives continuous previews to grown software projects. You need to have a working Dockerfile and nothing more. It works for frontends, backends, all kinds of tech stacks and languages.

    We build this so you do not have to. Give your developers the power of continuous previews today. If you have a Dockerfile you are good to go in minutes.

    Level up!

    WunderPreview: Get a live preview environment for every new feature.
    Works for every tech stack. 30 days free trial. No credit card required.

    Keep things moving with automated previews.

    Screenshot of WunderPreview Dashboard