Velocity is a measurement of how many story points a software development team can finish within a sprint (usually one or two weeks). These points are set by the software development team when they review a ticket and estimate how complex the ticket is. When a team measures this output over a period of time, generally they have a consistent amount of story points they can deliver in a sprint and their velocity is known.
Improving developer velocity is directly correlated with performance. McKinsey published an article in April 2020, where they cite that companies in the top 25% on their Developer Velocity Index grow up to twice as fast as companies in their same industries. Intuitively this makes sense since delivering more allows the development team to learn through iterating and improving.
One might argue that velocity alone doesn’t make for great software, but assuming a development team is aware that quality is important, one can see how velocity usually helps. The ability to deliver quickly also allows a development team to address quality issues quickly. It’s easy to argue that development teams with high velocity have the ability to deliver better quality software because they can address issues quickly.
In the same study, McKinsey highlighted several factors that allow a software development team to move quickly. Specifically they highlight that Technology Tools are an incredibly important dimension to velocity and business outcomes. And the most important tools are: Planning, Collaboration, Development and DevOps tools.
In this post I’m going to discuss the top 5 ways Ephemeral Environments can improve developer velocity by touching on how they are a Collaboration, Development and DevOps tool. As we’ve spoken about in our article "What is an Ephemeral Environment?", ephemeral environments are spun up on demand and contain the code and data that approximates production closely. These environments are used by development teams in the software development process to test, debug and ensure features are built correctly before code is pushed to production.
Here are the top 5 ways ephemeral environments can be used to improve developer velocity
1. Ephemeral environments are a DevOps tool designed to remove the staging or QA environment bottleneck
Traditional pre-production ecosystems usually have a limited amount of environments for developers. The staging or QA environment is generally used as a step before production where all code is merged and tested. Most organizations have one or very few of these environments, so as the organization grows these environments become a bottleneck in the process as all code must be tested here before production.
With ephemeral environments, the traditional idea of “staging” is gone. Every feature branch is contained in its own isolated environment and becomes its own integration environment. There is no longer a need to have a single testing and integration environment where all code must merge before going to production. With ephemeral environments you have a limitless supply of environments for any purpose.
2. Ephemeral environments are a collaboration tool designed to allow for “early and often” feedback
Feedback is the lifeblood of great products. If you’ve ever read Andy Grove’s book on high output management, you know he does an amazing job of discussing how rework is so costly. If you haven’t read this book, I highly recommend it, even if all you read are the first few chapters where he discusses trying to cook a high quality egg repeatedly, in under three minutes. In summary, Andy suggested through this analogy that finding issues/defects early in the egg cooking process is the most important part of consistently cooking a high quality egg in under three minutes.
Likewise in software development, getting feedback and finding quality issues early in the development cycle reduces costly rework and improves velocity. If a product is delivered to a customer that doesn’t work or has bugs, it has to be reworked and go through the entire process again. Or if a product manager or designer doesn’t have a way to see changes until an engineer is finished with development, there is a high likelihood they will spot something wrong and rework the solution. These are all examples of wrotten eggs in the process that hamper developer velocity.
With ephemeral environments, rework can be minimized because stakeholders become a part of the development process. When an ephemeral environment is created, URLs to the environment are created so stakeholders can see progress while code is being developed.
At Release, we highly recommend to our customers that they create a PR as soon as a developer starts working on a feature so a Release Ephemeral Environment is automatically created. When the developer pushes code to their source control system, the environment is updated making it a live reflection of the feature during development. Product managers, designers and QA are automatically notified when changes are live and they can preview those changes and give feedback immediately.
At Release, we will also share our own ephemeral environments with our customers as we’re building a feature so we can get feedback directly from the people we’re making the software for before we release it to production.
3. Ephemeral environments can limit rework and thus increase developer velocity.
Ephemeral environments are a developer tool that allows for full integration and smoke testing on isolated features
Traditional continuous integration (CI) is the idea that your developer process should constantly be testing as a developer pushes code. What this leaves out many times is that most CI systems only perform unit tests continuously. Unit tests are meant to test small units of code and not the entire system as a whole. Integration and Smoke tests are where full paths of user experience can be tested. Usually Integration and Smoke tests are left to be tested only when the code makes its way via a merge to the mainline code branch and a traditional staging environment.
Again, if we refer back to Andy Grove’s three minute egg analogy, this step of running Integration and Smoke tests only when the code branch is merged to the mainline is extremely late in the process. If issues are found during Integration and/or Smoke tests, the developer has to start the development cycle again from the beginning after finding this issue too late in the process.
To add to the issue, if a team only has a single staging environment, the bottleneck around this staging environment is exacerbated with developers waiting for Integration and Smoke tests to be run on this single environment. On top of this, many code changes/features/branches may have been a part of the mainline merge making finding the cause of failed Integration/Smoke tests difficult and time consuming.
With ephemeral environments, Integration and Smoke tests can be run when the ephemeral environment is created for a feature branch. This ensures that Integration and Smoke tests are run as frequently as unit tests so developers can find issues early in the process. Additionally, Integration and Smoke tests run against a single feature change/branch will isolate changes against the mainline and make finding the root cause much easier.
4. Ephemeral environments are a DevOps tool that allow for experimentation with infrastructure
Making changes to infrastructure is hard and when a developer introduces the need for an infrastructure change it’s costly in time across the board. In a traditional environment setup (without ephemeral environments) this will result in an overall slow down in developer velocity as the shared staging environments must be updated by the DevOps team so the developer has some place to test their changes and new infrastructure.
With ephemeral environments, this testing can be done in isolation and does not impact any other developer. For instance, with Release Ephemeral Environments, a developer can add services, environment variables, new infrastructure dependencies, new datasets/databases on their own through use of environment templates (environments as code) to experiment and develop without interfering with any other developers work or environments. This results in higher developer velocity again through minimization of rework and bottlenecks on shared resources.
5. Ephemeral environments are a collaboration tool designed to be an agile/scrum catalyst
Many organizations have made the move to Agile/Scrum but their infrastructure and technology haven’t adapted to support a more iterative approach to building software. The entire premise of Agile/Scrum is for teams to be empowered and driven by early and often feedback. If your organization is on Agile/Scrum and you’re still using a single or few staging environments, you’re technologically hampering your process improvements. Ephemeral environments are the homes and office buildings where agile teams live, work, build, and play.
Ephemeral environments are a catalyst to the Agile/Scrum methodology. When a developer does a pull request the ephemeral environment is created and collaboration on the feature can begin. The team is free to iterate, share, nand solicit feedback all while keeping the rest of the organization freely moving with their own ephemeral environments. Stakeholders are a part of the development process and true customer driven development, which is the heart of the Agile/Scrum methodology, can occur.
Conclusion
Ephemeral environments turbo charge development velocity by eliminating bottlenecks in the process (DevOps Tool), including stakeholders in the process (Collaboration Tool) and improving product quality (Developer Tool). All of these factors were highlighted in the McKinsey report on developer velocity as critical and ephemeral environments are an investment that will put your organization in the top 25%.
Photo by Maico Amorim on Unsplash.
Top comments (0)