I frequently come across SAP developers that are eager to innovate but face technology hurdles that limit them. This is particularly frustrating since technology should serve as an engine for growth. This is not just my opinion; it has been proven by all the world's largest companies. If you are not innovating, you risk being passed up by companies that are. So the question arises, how can organizations accelerate developer productivity in an environment where waiting months for a shared development system is the norm?

To answer this, first, we have to thoroughly understand the motivation.

## Can technology drive business value?
Top-performing companies know that internal IT is as critical as customer-facing technology. However, metrics for internal IT are not as straightforward, leading most companies to only see it as a cost center. Too often, the inability to correctly measure ROI leads to missed opportunities.

IT becomes a value driver and innovation engine when the ROI is measured correctly and a framework to improve productivity is in place. Organizations that do not leverage IT as a value driver risk being surpassed by those that do. This blog explores how improving developer productivity is the catalyst for building and scaling high-performing technology and organizations.

## Measuring the unmeasurable
How do you measure developer productivity? It is not as easy as it may seem. If developers are evaluated against the wrong metrics, they will learn to game the system.

For example, if you measure lines of code, it's easy to write overly complex code for simple things. This is not the right approach, as it will quickly lead to technical debt.

So then you might think, let's measure productivity based on the number of transports. That can lead to increased risk as developers may rush to create a high number of transports, increasing the likelihood of a failure in production. Not to mention, transport management also poses risks.

What if you instead focus on the number of features completed. This is not fair since not all features are equal; some are more important than others and vary in implementation difficulty.

An observant reader may note that the metrics above are sacrificing speed or stability. And, of course, we want it all!

## No trade-offs between speed and stability
Instead of measuring productivity via isolated metrics, consider adopting the framework based on Accelerate.
1. Delivery lead time - the time it takes for a feature to make it from the first line of code to production
2. Deployment frequency - the number of deploys to production
3. Time to restore service - the time it takes to correct an issue in production
4. Change rate fail - the percentage of deploys that cause production issues

When these metrics are optimized collectively, you notice that there isn't a sacrifice between speed and stability. Instead, you set the foundation for becoming a high-performing organization. Elite IT teams achieve the following results:
1. Delivery lead time - less than 1 day
2. Deployment frequency - on-demand
3. Time to restore service - less than 1 hour
4. Change rate fail - 0-15%

## Culture guides everything
Metrics, frameworks, and technology are valueless if you don't also establish a healthy organizational culture.

 Healthy Culture 
The right metrics are used for positive change

 Toxic Culture 
Metrics are used as tools for control and culpability

Culture and process go hand in hand; they can be mutually reinforcing or mutually destructive.

Consider the shared DEV and QAS systems we've grown used to in the SAP world. These shared systems are intrinsically risky. As developers, we have the potential to break them, which would negatively impact everyone else on the team. So to mitigate the risk, companies put in processes and procedures that adversely affect productivity. With containerized SAP systems, you can eliminate the risk of adversely affecting others, allowing for a culture where you are free to try anything in your container.

## The modern approach to SAP development
You've likely heard it, "implement DevOps!"

DevOps is a broad term that is often overused or misused. Instead, you should focus on implementing CI/CD pipelines. Leveraging several established best practices that include:

* Isolated development ([personal SAP systems](/blog/accelerate-developer-productivity) on Nuve)
* Intuitive version control (GitHub, GitLab, etc.)
* Test automation ([ABAP Unit](/blog/fundamentals-of-abap-unit-testing), [abaplint](https://abaplint.org/))
* Test data management ([refresh SAP systems in minutes](/blog/abap-unit-testing-approaches) with Nuve)
* Git-based workflows ([abapGit](https://abapgit.org/), GitHub, etc.)

Implementing these best practices puts you in a promising position to increase productivity. Coupled with a healthy culture, your IT team can provide a competitive advantage and pass up competitors that do not value the performance of software delivery teams.

**Credits:** Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren Ph.D., Jez Humble, Gene Kim

**Credits:** Photo by [Carl Heyerdahl](https://unsplash.com/photos/KE0nC8-58MQ) on [Unsplash](https://unsplash.com/)

Leverage containerized SAP systems for DevOps

Learn how to improve developer productivity, the catalyst for building and scaling high-performing technology and organizations.

Accelerate developer productivity

Related posts

Getting started with abaplint

Infrastructure as code, DevOps, and the future of enterprise

Top 5 development headaches and how to make your life easier