Improving software teams performance

There have been many attempts to measure the performance of software teams. For measuring the delivery performance, this research decided to focus on the following four measures:

Measures of software delivery performance tempo

• Delivery lead time: The time it takes to go from code committed to code successfully running in production.
• Deployment frequency

Measures of stability/quality of the systems

• Time to restore service: Traditionally, reliability is measured as time between failures, however, in modem software products and services, which are rapidly changing complex systems, failure is inevitable, so the key question becomes: “How quickly can service be restored?”
• Change fail rate: Percentage of changes to production fail (including, for example, software releases and infrastructure configuration changes).

Results of this study demonstrate that there is no tradeoff between improving performance and achieving higher levels of stability and quality. On the other hand, this research has identified key practices that contribute positively to high performance. By achieving this, organisations can drive improvements in their outcomes.

Most of the practices described below, that improve our ability to deliver software with both speed and stability, also reduce the stress and anxiety associated with pushing code to production, known as development pain and burnout (physical, mental, or emotional exhaustion).

Development

Version control

Keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control.

Test automation

Have automated tests that are reliable. When developers are involved in creating and maintaining acceptance tests, the code becomes more testable and they care more about them and will invest more effort into maintaining and fixing them. Once you have these automated tests, it’s important to run them regularly (on each commit). Developers should be able to run all automated tests on their workstations in order to triage and fix defects.

Continuous integration (CI)

Each change triggers a build process that includes running unit tests. If any part of this process fails, developers fix it immediately.

Continuous delivery (CD)

It is a set of capabilities that enable us to get changes of all kinds into production or into the hands of users safely, quickly, and sustainably. The process of releasing new versions to users should be a routine activity that can be performed on demand at any time. Some of the key principles at the heart of continuous delivery are:

• Build quality in.
• Get essential feedback on the work we are doing so that we can course correct.
• Computers perform repetitive tasks; people solve problems.
• Relentlessly pursue continuous improvement.
• Everyone is responsible.

Trunk-based development

Developing off trunk/master rather than on long-lived feature branches, with very short lifetimes (less than a day). Having multiple long-lived branches discourages both refactoring and intrateam communication.

Architecture

Loosely coupled systems

Systems that are be loosely coupled can be changed and validated independently of each other. The goal of a loosely coupled architecture is to ensure that the available communication bandwidth isn’t overwhelmed by fine-grained decision-making at the implementation level, so we can instead use that bandwidth for discussing higher-level shared goals and how to achieve them. This kind of systems allow us meeting two important architectural characteristics:

• Testability: Can do most of testing without requiring an integrated environment.
• Deployability: Can and do deploy or release our application independently of other applications/services it depends on.

Tools chosen by each team

Infosec

This is a vitally important function in an era where threats are ubiquitous and ongoing. Building security into software development not only improves delivery performance but also improves security quality. Information security should be integrated into the entire software delivery lifecycle from development through operations.

Management

Limited work in progress

Available performance metrics

Creating and maintaining visual displays showing key quality and productivity metrics and the current status of work (including defects), making these visual displays available to both engineers and leaders, and aligning these metrics with operational goals. Using data from application performance and infrastructure monitoring tools to make business decisions on a daily.

Lightweight approval process

We often see change management processes that take days or weeks, requiring each change to be reviewed by a change advisory board (CAB) external to the team in addition to team-level reviews, such as a formal code review process. However, approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. Teams that reported no approval process or used peer review achieved higher software delivery performance. Finally, teams that required approval by an external body achieved lower performance.

Supportive work environment

Fostering a supportive work environment:

• Learning from failures rather than blaming
• Communicating a strong sense of purpose
• Investing in employee development
• Asking employees
• Giving employees time, space, and resources to experiment and learn
• Avoiding work overload
• Proper rewards
• Being fair

Good eNPS

Having better employee loyalty, measured by employee Net Promoter Score (eNPS). A sense of identity (high sense of belonging) can help to reduce burnout by aligning personal and organizational values.

Engaged leadership

Some characteristics of a transformational leader are:

• Vision: knows where the organization is going
• Inspirational communication: Communicates in a way that inspires and motivates
• Intellectual stimulation
• Challenges followers
• Supportive leadership
• Personal recognition

Product

E2E understanding

Teams have a good understanding of the flow of work from the business all the way through to customers.

Customer feedback seeking

Cross-functional collaboration

Development teams have the authority to create and change specifications as part of the development process.

Small batches

Products and features are sliced up into small batches that can be completed in less than a week and released frequently.