The 5 Ideals
Last updated
Was this helpful?
Last updated
Was this helpful?
Was this helpful?
The organizational environment must support DevOps. We can measure it with the “Lunch Factor”: how many people do we have to talk to over lunch to get things done? Reduce the lunch factor to a minimum.
Have fewer teams that can deploy more often independently.
Have an architecture that allows a fast turnaround time.
Developers must be empowered to work independently including that most integration tests must be run without an integrated staging environment (note: done right, contract testing might be a means to achieve that).
Developers should not have to understand a big codebase.
Developers must have the authority to deploy code to production.
Developers must not have to wait for other business units to get things done for them (like enterprise architecture review, database schemas, …).
Developers should solve the business problem and not spend most of their time on configuration and infrastructure tasks.
Put the infrastructure into a platform.
Reduce the lead time between code check-in and feedback to a minimum to connect the cause to the effect; ideally, know within seconds if a feature works or not.
Do trunk-based development to reduce the PR review and merge overhead.
We can only improve if we get feedback, so we should put as much feedback into our daily work as possible to get a little better each day.
Toyota had a cord along the assembly line that is expected to be pulled by any worker that sees a problem (the Andon Cord. If it’s pulled, they have 55 seconds to fix the problem, otherwise, the assembly line stops. The cord is pulled something like 3500 times a day (talk about feedback).
Big companies like Microsoft, Google, and Amazon only survived their technical debts because at some point they froze feature development.
The build time of Nokia’s own operating system Symbian was 48 hours before they “pulled the cord” and went with another OS (didn’t help them in the long run, though…).
Always take 20% off the development cycle to fix (or avoid) tech debt.
Enable greatness by having some engineers solely concentrate on dev productivity.
Have a virtual Andon Cord to fix things right when they happen.
Only a psychologically safe environment allows for new ideas, innovation, and to learn from errors. An environment where you get bullied for each production error does not support a fast DevOps cycle, because everyone wants to be 100% certain that it works, which results in big deployments with slow processes and more things that can go wrong per deployment.
focus on the things that bring value to the customers instead of building functional silos and long internal decision chains within the organization.