Apply for the Google Cloud DORA Awards!

Capabilities: process

Team experimentation

Even in many so-called agile teams, developers can only work on requirements or stories that are given to them. And despite the developers’ specialist knowledge, or what they discover in the development process, they can’t change those requirements and stories. In truly agile teams, what’s written on the story card is a reminder of a conversation between customers and the team. Stories start from the business outcome that they are trying to achieve or the problem they are trying to solve. Teams then decide on what needs to be done, and test whether it will achieve the outcome or solve the problem.

For your organization to fully benefit from modern software development techniques, you must empower your teams to experiment with real users to achieve agreed-upon business outcomes. In this paradigm, developers can quickly prototype and test ideas as they discover more about users and about the problem, and design solutions. Teams then incorporate what they learned into the design of the product or service. Using the lean product management method, these practices help teams ship features that add value to the organization, and ship those features more frequently.

Team experimentation is part of lean product management. This approach is often used in combination with capabilities like visibility of work in the value stream, working in small batches, and visibility into customer feedback. These capabilities predict software delivery performance and organizational performance.

How to implement team experimentation

DevOps Research and Assessment (DORA) research identifies three key components to team experimentation that drive software delivery performance:

  • The ability to work on new ideas independently, without having to get permission from outside of the team.
  • The ability to write and change specifications during development.
  • The ability to make changes to stories and specifications without having to get permission from outside of the team.

Based on these abilities, the following practices can help improve your team experimentation:

  • Empower teams. Empower teams and allow them to work on new ideas in pursuit of business goals that solve important problems.
  • Provide information and context. Providing teams with information and context lets teams make informed decisions about the right work to do. Measuring organizational outcomes provides information critical to making the best decisions, so teams are able to achieve expected outcomes and solve problems.
  • Leave the details to those doing the work. Allow your teams to change stories, specifications, and technologies when they decide it’s appropriate. Understand and acknowledge that they are the experts, and empower them to make the technical decisions necessary to get the work done. In the highest-performing teams and organizations, teams are allowed to make informed decisions about the tools and technologies they use.

Common pitfalls in team experimentation

When organizations implement team experimentation, they often face these common pitfalls:

  • Ignoring the importance of experimentation altogether. Don’t treat your technical staff as order-takers. It’s worse when teams are given specific direction on how to perform the work. Your technical staff are the experts, so empower them to make the technical decisions needed to get the work done.
  • Not providing opportunities or time for your technical staff to design and conduct experiments in quick and easy ways. Empower your developers to quickly prototype and test ideas.

Ways to improve team experimentation

To free your teams to find the best solutions, try some of these suggestions:

  • Hold regular hackathons. Hackathons are opportunities for the team to experiment and to work with and share ideas. They also have the added benefit of letting your team work with new technologies and tools.
  • Encourage teams to iterate on and continually improve solutions to foster experimentation. Many times the first solution to a problem isn’t the best. Improvements to one service or feature often yield improvements in others.
  • Allow developers and operators to talk to and observe customers. This kind of interaction provides more context and information that teams can use to solve problems and develop new ideas.

Ways to measure team experimentation

You might be able to capture some evidence of team experimentation in your systems, for example, by tracking permission requests for changing stories or specifications. However, we recommend using surveys to measure experimentation. The core idea is that teams feel the freedom to do this work and find the best ways to solve problems.

DORA research shows that high-performance teams are driven by the following measures:

  • Teams are able to work on new ideas.
  • Teams are able to do work without having to ask for permission.
  • Teams are able to make changes to stories and specifications during development.
  • Teams are able to make changes without having to ask for permission.

What’s next