iMasters.com - Knowledge for Developers.
Follow Us
Home Cloud & Infra Developer Team – Experiments Culture
Cloud & Infra

Developer Team – Experiments Culture

How to reduce waste, save time (and money), using experiments as a basis of the work between teams and people

Many times in my career, I have struggled with how to work in collaboration with different areas of a company. Dependencies between teams and people are the hardest in projects or tasks. In addition, various thoughts on how things must be done or executed cause frustration, wrong expectations, and, sometimes, conflicts.

There are many ways to solve this pain, but I want to bring you a different approach. A culture that incentivizes experimentation could help your teams or areas to get alignment, clear expectations, make concrete goals, and makes possible the fault, discarding unnecessary work and unlocking new ways of doing the job. It seems impressive, huh? Let’s dive deep into how to make this possible.

What is an Experiment

In product-led organizations, usually, the teams have a mindset of testing and validating hypotheses before delivering the solution to clients. This way of testing and validating things makes providing solutions that match the customer’s necessities cheaper and faster. Some teams named this mindset “Culture of Experiments”

There are a lot of ways of doing an Experiment. Some teams used A/B tests, and others built prototypes, but before going deep: what is an experiment?

An Experiment could be defined as:

A process to discover something and test a hypothesis or known fact.

In Science, an experiment is part of the scientific method responsible for acquiring knowledge. It involves 1) Observation, 2) Skepticism, 3) Hypotheses Formulation; 4) Test with experiments; 5) Analyzing data; 6) Report Conclusions. Please, take this information in mind because we will revisit it soon.

It seems complex and challenging to apply daily, but it is simpler than it looks. You will need to practice and double-check this way of working.

How to start

Instead of planning big projects for the quarter or year, you could focus on “what we want to achieve” or “what are the outcomes we want to target.” It’s easier to talk about than practice, but if you make a list of projects for a quarter, you will probably not achieve a good part of these items. For example: how many projects did you finish last quarter? This is because things change constantly, and you need to adapt plans as soon as the situation claims.

With well-defined outcomes, observe what is happening around them. What is working well or poorly? What are the impacts of this, today or in a mid-term? After these questions, you can formulate hypotheses to create a new experiment.

How to execute Experiments

Defining what experiments and how your team will run experiments could be challenging. When the hypotheses start to be listed, you will see a lot of excellent experiments to run, and it will take time to decide how to prioritize or organize them. Another issue is the timing and the effort enough that will take.

Considering these issues, I want to share some tips based on my experience.

Discover the “price”

You need to know how much effort or investment the experiment will demand. An example is an experiment of doing in-company events to increase employer branding. Will we have a coffee break? Is it necessary to give company gifts? If yes, the cost of this experiment could be higher than other experiments. It will help if you put it on the scale.

Limit the number of them

There is a temptation to run a bunch of experiments simultaneously, but you will probably do poorly and without enough depth because of their concurrence. Even if you have enough people to run many of them, you need to check the dependencies and how much cross-work the experiments will take. Limiting the work in progress is a maxim of any efficient team.

Define the roles and responsibilities

Whether you have different people from different areas running experiments together or even if only one team does it alone without interdependencies, it’s good to define roles with their responsibilities.

An example of a good role is the owner of the experiment, like an “Experiment Lead.” The responsibilities could be:

  1. Document the before, during, and after the experiment, giving visibility to the experiment, its execution, and results;
  2. Manage dependencies and removing experiment impediments;
  3. Create a proposal describing where the project or responsibility must live after the experiment finishes.

This role must be defined because the experiments must have an owner, a responsible person, to make the experiment happen.

Organize Experiments around themes

Some of the experiments will have a theme. It could be nice to have them grouped on specific fronts, collecting and burbling new ideas related to the topic. New experiments may arise from the learnings on running experiments in a particular subject, and the group can benefit from this.

Another benefit of grouping by themes is ensuring that the outcomes have a clear association with the tactical work of the experiments. If an experiment runs without impacting results, this could waste effort and time. In a group with all the experiments, this could be easily detected.

Give space to, and encourage different opinions

It seems cliche, but when you run in an experiments mode, you must make possible different ideas being created or experimented on.

It might be tempting to avoid these divergent opinions or experiments that you don’t believe will succeed.

Make people empowered

Experiments Culture is related to empowering people to validate the hypothesis. We need to take advantage of human creativity. To make this possible, I recommend that you run experiments in a self-management mode.

The roles I mentioned before and some explicit restrictions will help the people validate the hypothesis without supervision or any way of tracking the work.

It could be strange for somebody that has yet to work in a self-management team/company, but you can adopt some things slowly. These definitions that I mentioned before (roles and responsibilities) will help to remove the necessity of syncs or reports.

A simple example is creating a sync artifact that people could make visible the progress, learnings, or even the end or start of an Experiment. It could be a simple message using a template via your communication platform (e.g., Slack, Teams). You can make this agreement and make explicit the agreement when posting the progress.

Another tip is to make the themes visible so people can run the experiments knowing possible hypotheses. Again, you can use your communication platform, like Slack or Teams, to create channels related to the themes. Anyone who wants to run experiments or wants to know about the ones running will be up-to-date and invited to follow up.

Last one thing

You are probably asking now, “why do all of these things reduce waste and save time and money?”. Because when we focus on experiments:

  1. We don’t waste time with guesswork, and we avoid possible big projects that could fail after a lot of spent energy. Small interactions make us faster in testing and proving the hypotheses (impacting the time-to-market);
  2. With experiments, we incentivize people to prove some ideas before doing a bunch of projects or initiatives without testing them, creating maturity and increasing self-criticism. How many projects did you see being born giants but dying in the dark without any reflection or feedback?
  3. We give people the power to discard things before spending energy on them — and probably discard hypotheses as soon they fail instead of insisting on doing poor projects. So, experiments create a safe environment to bring ideas and discard them if they don’t prove themselves good. Safe environments help the organization be more creative, inclusive, and human — consequently having people engaged with their work;
  4. Your teams will start to make smarter decisions on using budget because the culture of the experiment forces them to focus on spending less energy, time, and money to prove that they will succeed. The question to always be done is, “how can we test it cheaper?”;
  5. You will reduce the size and complexity of big-time cycles (e.g., meetings, annual planning, etc.) to decide on the following initiatives. The challenge will be what the next projects will reduce because people will experiment more before prioritizing these initiatives, creating solid projects, evidenced by comprised hypotheses.

Running experiments with good frequency will probably make your organization achieve the necessary maturity to reach the desired outcomes more efficiently. Additionally, you will have a group of people motivated by the goals, with the necessary autonomy to make decisions on moving on with initiatives or not. Why do you not test? 🙃

References

Written by
Eduardo Matos

Musician, programmer, interested in evolutionary organizations, addicted to comics, tennis and lego. In recent years I have focused my career on people leadership, and I have deepened myself in organizational design and software architecture - sociotechnical systems ;)

Leave a comment

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Related Articles

Cloud & Infra

What is the potential of Software Delivery for companies

Companies that invest in software to improve operations enjoy a significant competitive...

Cloud & Infra

Spot By NetApp analysis of Elasticgroup usage at Convenia

In this article, I aim to tell a little about how we...

Cloud & Infra

Cloud solutions allied with companies, but also with developers

In a global scenario, where technological innovation is constant, standing out from...

Cloud & Infra

The DevOps Path

Some time ago, I am about to complete 20 years of career,...