Sharing on Accelerate

class: center, middle

# Sharing on

.image-50[![](https://miro.medium.com/max/633/1*q1OdSUfTWG6YDsF87c8FOA.png)]
---
# Legend

<i class="material-icons">emoji_objects</i> - Supplementary information that I added in

---
<style>.enlarge ol {font-size: 30px;}</style>

# Objectives
### 1. Metrics to optimize towards
### 2. Capabilities to develop
### 3. Knowledge sharing
---

# Measuring performance
Velocity is a good for capacity planning
--

.red[but bad as a productivity metric]

Why?
- Relative and team dependant
- Can be gamed

---

# A good measure of performance
**Outcomes**, not ouput

**Global**, not local
- Teams not pitted against one another

---
# Metrics of software delivery performance

### Lead time for changes
Time taken from code committed to code in production

Why not time from customer making a request to request satisfied?

Estimates are highly uncertain. <br> E.g. Time taken to design feature vary feature to feature

---
# Metrics of software delivery performance
### Lead time for changes
### Deployment frequency
How often is your software deployed to production

---
# Metrics of software delivery performance
### Lead time for changes
### Deployment frequency
### Mean-time-to-repair (MTTR)
Failure is inevitable, how quickly can service be restored?

---
# Metrics of software delivery performance
### Lead time for changes
### Deployment frequency
### Mean-time-to-repair (MTTR)
### Change failure rates
% of changes to production that result in degrated service or require remediation

---
<style> 
table {
    border-collapse: collapse;
}
th, td {
    padding: 10px;
    border: 1px solid ;
}</style>

# Classifying based on metrics

2017  | High Performers | Medium Performers | Low Performers
------------- | -------------
**Lead Time for Changes**  | Less than one hour | Between one week and one month | Between one week and one month*  
**Deployment Frequency** | On demand (multiple deploys per day) | Between once per week and once per month | Between once per week and once per month*
**MTTR** | Less than one hour | Less than one day | Between one day and one week
**Change Failure Rate** | 0-15% | 0-15% |  31-45%
*Low performers were lower on average but has the same median

*2019 version out on the internet*
---

class: center middle
# Lower lead time and higher deployment frequency do not affect stability <br> (change failure rate)

---
class: middle center
# What's the point?

--
![](./impacts-of-sdp.png)

---
# Impacts of software delivery performance

### Organization performance
- Profitability
- Market share
- Productivity

### Noncommercial performance
- Quantity of products and services
- Operating efficiency
- Customer satisfaction
- .red[Organization & mission goals]

---
# Improving software delivery performance

### 5 categories of 24 capabilities

1. Continuous delivery
1. Architecture
1. Product and process
1. Lean Management & Monitoring
1. Cultural

---
# 1. Continuous delivery
1. Version control
1. **Deployment automation**
1. Continuous integration
1. **Trunk-based development**
1. **Test automation**
1. Test data management
1. Shift left on security
1. **Continuous delivery**

---
# Deployment automation

Machines are better at mundane tasks
--

- Less prone to error

Automate the mundane tasks so developers can spend more time doing what they do best, solving problems

---
# Trunk-based development
Develop off master branch

Branching is not bad per se
--
.red[, long lived branches are]

Long lived branches
- Minimise merging and integration
- Discourage refactoring and intrateam communication

Short-lived branches (daily)
--

- <i class="material-icons">emoji_objects</i> Gives us room for code reviews 
---
# Test automation
Developers create and maintain the tests

Reliable automated tests

---
# Test automation

<i class="material-icons">emoji_objects</i> Keep your tests clean too
- Dirty tests are very bad
--

- As you modify production code, old tests will fail
--

- Messy test code makes it hard to get those tests to pass again
--

- Cost of maintaining test suite goes up significantly, becomes a liability
--

- Team discards writing tests because estimates are getting too large
--

- Without a test suite, team loses ability to ensure that production code changes do not break anything 
--

- Team starts to fear making changes to production code, dare not refactor 
--

- Production code starts to rot

---
# Continous delivery

Your system 
- Is in a deployable state throughout its lifecycle
- Can be deployed to production at any time

---
# 2. Architecture

1. **Loosely coupled architecture**
2. **Empowered teams**

---
# Loosely coupled architecture

Focus on **deployability** and **testability**

Loosely coupled architecture helps high performing groups to
- Test, deploy, release and change their systems without dependencies on other teams
- Complete their work with minimal communication & coordination with people outside their team

Allows an engineering organization to scale <i class="material-icons">emoji_objects</i>  by reducing overhead of communcation

.image-comm[![](https://martinsitconsulting.com/wp-content/uploads/2019/09/Communication_channel_black_white.png)]

---
# Loosely coupled architecture

Microservices is a mean, not an end.

<i class="material-icons">emoji_objects</i> Don't end up building a distributed monolith.

---
# Loosely coupled architecture

Conway's Law
<blockquote>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.</blockquote>

---
# Empowered teams

Let teams decide on their tool choices, they know best

There's still a place for standardization
- If a tool makes life easier, engineers will adopt them of their own free will

Focus on outcomes, not tools or technologies

---
# 3. Product and process
1. Customer feedback
1. Value stream
1. Working in small batches
1. Team experimentation

---
# 4. Lean management & monitoring
1. **Change approval processes**
1. Monitoring (i.e. User monitoring)
1. Proactive notification (i.e. System monitoring)
1. WIP limits
1. Visualizing work

---
# Change approval processes

External approvals (such as a manager or a CAB) were negatively correlated with
- Lead time
- Deployment frequency
- Mean-time-to-repair

.red[External approvals had no correlation with change failure rate]

---
# Change approval processes

Recommendation based on results
- Lightweight change approval process based on peer review (e.g. pair programming or intrateam code review)
- Deployment pipeline to detect and reject bad changes

Can be used for all kinds of changes, i.e. code, infrastructure and database changes

---
# Change approval process
A focus area of the [2020 State of DevOps Report](https://media.webteam.puppet.com/uploads/2020/11/Puppet-State-of-DevOps-Report-2020.pdf)

---
# 5. Cultural
1. **Westrum organizational culture**
1. Supporting learning
1. Collaboration among teams
1. Job satisfaction
1. Transformational leadership

---
# Westrum organizational culture

| Pathlogical (Power-Oriented)  | Bureaucratic (Rule-Oriented) | Generative (Performance-Oriented) |
|-------------------------------|------------------------------|-----------------------------------|
| Lower cooperation              | Modest cooperation           | High cooperation                  |
--

| Messengers "shot"               | Messengers negletcted        | Messengers trained                |
--

| Responsibilities shirked      | Narrow responsibilities      | Risks are shared                  |
--

| Bridging discouraged          | Bridging tolerated           | Bridging encouraged               |
--

| Failure leads to scapegoating | Failure leads to justice     | Failure leads to inquiry          |
???
Human error should be the start of the inquiry, and not the conclusion
--

| Novelty crushed               | Novelty leads to problems    | Novelty implemented               |

---
# How to change the culture?

<blockquote>... that the way to change culture is not to first change how people think, but instead to start by changing how people behave - what they do</blockquote>

--
.center-img[![](./culture.png)]

---
<style>.image-70 img {
    height: 425px;
    width: 100%; 
 }</style>

# The big picture

.image-70[![](./overall.png)]

---
# What's the point?
### 1. Metrics to optimize towards
- How to measure
- How to optimize

--
### 2. Capabilities to develop
- What have we gotten right 
- What to invest resources in