I recently watched Martin Fowler's talk on What Does Tech Excellence Look Like? It's a talk about technical excellence in an organization and why it's important. If you haven't already watched it, I highly recommend you do so!

The talk starts with a quote on the state of DevOps report which states:

We can not assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.

Martin does not buy such statements so he reached out to Jez Humble & Nicode Forsgren for more information. In their research they correlated IT performance to Organizational Performance.

What is IT performance?

Cycle Time:

• The time it takes to build something from an idea and put it to production.
• The faster your cycle time, the more advantage you have in terms of experimenting with things and trying things out.
• The research indicated that cycle time had a direct correlation with how good an organization's performance was.
• Allows us to get early information on whether new ideas are worthy to pursue.

Why do we want to do fast cycle times?

• Because we want this early information of whether new ideas or features are beneficial or not.
• We want to be able to see if we're on the right path and course correct immediately.
• It's worth paying more to get this degree of information

Learnings

1. It is important for an organization to get quick feedback on new initiatives.
2. The faster they can implement features and bring them to the end users, the greater their edge over competitors.

Mean Time To Recovery (MTTR)

• The time it takes to fix something broken on production.
• It is more important than Mean Time Between Failures (MTBF) for most failures (MTTR > MTBF)
• By putting something into production, it's more important that you can realise something's gone wrong and fix it than it is to prevent the failures in the first place.

Learnings

1. For most failures, it is better to optimize the time it takes to recover from failure rather than work on increasing the duration between failures.
2. This is because being able to quickly detect and fix failures means better logging and monitoring for the software which increases it's reliability.

Continuous Delivery

• Building the software in such a way that you're always able to put the software into production.
• Important in the business sense - does it give me enough incremental shift to get value?
• Requires lot of discipline from the team. It's not an easy thing to do but is worth it.

Learnings

1. Continuous delivery requires very mature software development practices.
2. The codebase (main branch) should always be in a deployable state.
3. There should be proper testing in place to avoid any accidental bugs going in the system.

Team Structure

• Another important aspect of a good organization is how it sets up its teams.
• We want small teams that are able to collaborate together but they need to be business focussed.
• Teams of dozen people (2 pizza teams - Amazon).
• All teams should be customer facing. They should have a path to the customer. (This is another aspect of Amazon 2 pizza teams that people miss out on)
• Humans naturally silo. You cannot avoid it but you can organize the silos in a way that are beneficial or least harmful. You can do that by focussing on business oriented teams.
• Teams should have long life, longer connection to that business group. If we're forming teams for six months and then they go back into a pool, then it results in lower quality software.
• Teams should be autonomous. They should have everything they need to deliver useful software to the business. That means they not only have access to frontend components, but all the way to the backend and connections to the business people.

Learnings

1. How we structure and empower teams is important to an organization's efficiency and competitive edge.
2. Teams should be small in size and business oriented.
3. Teams shouldn't be separate or kept in silos. They should have direct interactions with end users. They should also be long running so they can form the necessary context around the codebase, increasing the quality of the software. ```

Trust

• Team members should be able to trust each other.
• Trust each other so they can share knowledge, share problems, where people aren't afraid to ask for help, that they have integrity within the group so that when someone says they want to do something, you actually believe what they say.

Learnings

1. Trust forms the basis of team happiness and how efficient members become.
2. If team members aren't comfortable, it reduces the team productivity.
3. We should strive to create an environment that fosters trust, bonding and happiness.

Technology Led

• It's not like leader of the team should program everyday but they should be able to. They understand what is going on in the software being built.
• Recognition should come from the peers, it comes from value of continuous learning.

Learnings

1. It is important to have a strong tech team led by someone who is equally adept in technology.
2. Leaders should be equally hands on as the rest of the team even if they don't code on a daily basis.
3. Peer recognition is more important than manager recognition.
4. An environment which values tech skills and encourages continuous learning is beneficial for the organization.

Bringing it all together

Within a team, we want to combine software development and business orientation but with a value of each other and communication through short cycles of rapid delivery of software.

Analogy:

Trying to deliver software this way is like having a vehicle for a long distance journey.

• You need to be careful of the health of the vehicle. The vehicle is the codebase (quality of the codebase is important) and also health of the team (is the team interacting well with each other, are they learning well).
• What the business provides is direction of travel. You can have the healthiest vehicle in the world but if you're going the wrong way, it's not going to be helpful.

The key thing is the short cycles delivering business valuable software.

Can we do this change in one go?

• No, it's not possible since an organization contains of a large number of people.
• We need to learn how to prioritize

How to prioritize?

• Prioritization comes from saying to ourselves, what are the strategic pieces of software and what are the utility softwares

Strategic

• How does it affect your differentiation in your business
• Is it something that is vital to do things better
• Here we're concerned about speed (improving cycle time), we want inventiveness (let's get ideas, put them in production before competition does).
• Here cost doesn't matter that much since your business value (the value that the customer is getting) should overwhelm the cost. You should focus on how to generate value rapidly not on how to reduce cost.

Utility

• Doesn't help the business strategically
• Example: payroll system
• Here we're concerned about keeping costs low and avoiding disasters

Learnings

1. A technically adept organization keeps the cycle time between software deployment and adding business value low.
2. The team and codebase needs to be constantly maintained while the business provides the necessary direction. (We don't want to build features that are not required or don't add any business value)
3. It is important to differentiate between strategic and utility software and treat them differently as they have very different goals.

Differences from Two Speed IT (McKinsey)

• Making software shouldn't just be about improving frontend, it's also about improving backend.
• Be wary of bimodal things.

• In order to get speed and flexibility, you need high quality software!
• If you've got lots of bugs in your system, it's going to slow you down. If you don't pay attention to the way software is constructed so that it's nicely modularized and easy to understand, it's going to slow you down.
• Quality does not mean slow speed, it actually increases speed by improving code quality and extensibility.

Learnings

1. The strategic-utility method focusses on business functions and how we can go ahead of competitors.
2. The bimodal method focusses on backend and frontend and tries to optimise for frontend to increase business value.
3. The strategic method focusses on high quality resulting in greater speed and flexibility while bimodal believes that since frontend needs to be fast, it'll be error prone and since backend is high quality, it's development will be slow.

Note: All images have been taken from the presentation