My notes from the DevOps Handbook

by Gene Kim, Jez Humble, Patrick Debois, John Willis

Keep our improvement planning horizons short

Measurable improvements or actionable data withing weeks.

• Flexibility to replan quickly
• Decrease delay between work and resulting improvement: this strengthens feedback loop reinforcing desired behaviors, successes encourage investments
• Faster learning from first iteration, faster integration of learnings in the next one
• Reduction in activation energy for improvements
• Quicker realization of improvements in the daily work
• Less risk that the project fails before showing outcomes

Reserve 20% of cycles for non functional work and reducing technical debt

I would even say 49% - technical debt + testing

Organizations that need the process improvement the most are those that have the least amount of time to spend on improvement. This is especially true because of technical debt.

We actively manage this technical debt by ensuring we invest at least 20% of all development and operations cycles on refactoring, investing in automation work and architecture non-functional requirements, such as maintainability, manageability, scalability, reliability, testability, deployability and security.

Product management should take 20% of team's capacity and give it to them to spend as they see fit. You can't get away with much less than 20%. If the state is very bad, 30% or even more might be needed. Without paying this 20% tax, the debt will increase to the point where the entire organization will spend all of the cycles paying it down.

Alleviating added pressure of technical debt from workers can also reduce levels of burnout.

Increase the visibility of work

To be able to know if we are making progress, everyone in the organization should know the current state of work and this information must be up to date.