How to accelerate and scale team performance
Characteristics of high performing teams
As a developer or a team member in an agile team, you may ask, are we doing things as we should?
Your gut feeling may give you an intuitive answer. Maybe having a headache over some time-consuming flaws occasionally slows things down.
Is it possible to measure and distinguish what affects software delivery performance?
Yes, I think so. The authors of Accelerate¹ convinced me. Their research during four years shows that throughput and stability correlate, and it also has a positive impact on a company’s profitability.
The research has study thousands of organizations globally. They are investigating what capabilities, architecture, practices, tools, culture, and patterns that have an impact on the overall performance delivering software.
Results from the science
It’s clear that embracing the DevOps practices has a significant impact on performance and that organizations with high performance has a:
- Higher frequency of code deployments
- Faster lead time from commit to deploy
- Faster mean time to recover from downtime
- Lower failure rate
My take-aways
The key capabilities that I take away is:
- Performance-oriented culture (Generative culture) — A culture with a focus on the actual problem instead of focusing on internal politic or fulfilling internal rules has a significant impact on the software delivery performance. Power oriented and rule-oriented culture harms performance, and work satisfaction.
- Trunk based development — Use short-lived branches (less than a day). Small batches of change reducing migration work and risk for re-work.
- Continuous integration — Have everything in a version control system. The research showed that keeping all application configuration code in a VCS needed to spin up new environments has a stronger correlation with performance than the actual application code.
- Continuous deployment— Deploy small and often. Eliminate deployment pain. Invest time and resources on creating a smooth process until it supports daytime deployments. Let the team choose the appropriate tools.
- Architectural characteristics — The actual choice of technical framework is not the crucial part. Greenfield or old legacy doesn’t matter. However, what matters is that the services and applications are loosely coupled and can be deployed and tested quickly and independently without any need of external dependencies such as other team’s progress or a specific status in test environment.
- Empower teams— As an extension of architectural characteristics, it’s essential to empower the team with responsibility and mandate to make their own decisions without approval from external authority, for example, regarding the choice of tools, design, functionality. If there is a need for external authorization, the innovative spirit and tempo in the team goes down, and as a result, it’s harder to scale performance.
- Lightweight change process — Adding a Change Approval Board (CAB) or similar doesn’t necessarily reduce risk or increasing stability. It’s complicated and time-consuming to analyze the code from an external part. Research states that a code-review from your college is equally secure, and it is also speeding up the deployment cycle and recovery time after an outage.
- Sustainability — Create a sustainable, and great work/life balance is essential. Many may think that focusing on performance, is equal to add more pressure on the employees by speeding up the workload to overwhelming and untenable levels. Results from the research states the opposite. It has to be sustainable and healthy. Work smarter, not harder. Burnout and high-stress levels has many adverse effects on the team and the individuals in particular. Automate all repetitive tasks (builds, tests, deployments) and let the team be responsible for tasks requiring more logical challenges, such as improvements, decision making, and experiments.
Conclusion
Performance is not about working harder; it’s about working smarter at an organizational level.
Challenges
Tools and technology to automate and accelerate is pretty straight forward. There is a lot of best practices available. Let the teams pick and mix what’s suitable. But it’s essential to invest time to get appropriate tools.
To achieve and enable the other capabilities according to the research, I think the biggest and most pressing challenges are:
- Change of cultural norms can be challenging (Of course, only if power or rule-oriented culture is present). It can be hard to change the current social norms, requires transformative leadership.
- Create the architectural prerequisites (loosely coupled in all dimensions — as in code, testability, deployment). Most significant challenge here: separate or untie old and current dependencies. Can easily be complex, even within a greenfield microservice architecture.
- Empower the agile teams — Empower team and allow them to steer the agenda within their ecosystem totally by themselves. Also, give the team a lightweight change process. Biggest challenge: It requires a lot of courage and trust from management.
”The level of job satisfaction, identity, and engagement are crucial. The high performance and most innovative companies know this and capitalizes on this.”
Final thoughts
Your current state of throughput and stability is a transparent way of measuring your team’s and organizational performance.
And by that conclusion: the average time it takes for a commit to reach production and the time between deploys is probably a more important KPI than you think. Minutes, hours, days, weeks, or months? At what end of the scale are your team?
Of course, it’s individual what capabilities that needs more focus. Either way, I think it requires courage, trust, and patience to invest time to improve.
Just by asking, why are we doing this? Can anyone explain? ”Business as usual” should never be something to strive for. Have the courage to experiment and test need ideas and allow failures. High throughput and frequency of deploys minimize risk. Fail-forward and learn from the feedback.
It can raise job satisfaction for everyone and make it awesomely to login Monday morning starting a new week. Knowing we use our time at work wisely and spending our energy on the right things. When the tedious manual work eliminated and you can instead focus on the new cool features, maybe it’s even your brilliant idea that comes up from last week’s feedback loop, approved by your team this morning. Maybe A/B test the idea before lunch in production.
Reflections based on reading: [1] Accelerate: the science behind DevOps: building and scaling high performing technology organizations / Nicole Forsgren, PhD, Jez Humble and Gene Kim
