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.
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.
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.
So now we know that the feedback loops should be as fast as possible. The ideal situation would be:
Wouldn't that be nice?
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?
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.
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.
This is when the team starts to create a system where they can spin up preview environments on demand. Either they
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:
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.
WunderPreview: Get a live preview environment for every new feature.
Works for every tech stack. 30 days free trial. No credit card required.