Is DevOps Practicing? AI is transforming how we write, test, and deploy software. DevOps practices that felt “standard” are being re-examined. What should we hold on to?What should we let go of? What does DevOps need to be NOW?
Feature Factory Ability without Intent DevOps gives teams the ability to change fast. But ability without intent creates waste. Clear Direction To change meaningfully, you need a clear direction. This is where goals — Objectives — become essential.
practice of continuous change OKR = the direction of that change When connected, they form a reinforcing loop that builds an organization's capacity to change. This talk explores how OKR and DevOps can work together to make change real. DevOps Needs a Direction-Setting Partner
KAKEHASHI Inc. Focused on Agile Software Development Process and OKR Book Author of エンジニアのための⾃⼰管理⼊⾨: An Introduction to Self-Management for Engineers アジャイルチームによる⽬標づくりガイドブック: 敏捷團隊⽬標設定指南｜OKR 落地與成果導向實踐法 ⼀番やさしいアジャイル開発の教本(Co-Author): comprehensive guide to agile for beginners Ikuo Odanaka (ikuo/190)
become hollow numerical targets or task lists? • What does DevOps actually 'practice'? • How can OKR and DevOps combine to make change real? 3 Questions This Session Will Explore
future that does not yet exist, and commit a team to moving toward it. They are not a performance management tool — they are a direction-setting tool. OKR : Articulating an Ambitious Future and Committing to It
in the 1970s. John Doerr brought them to Google, where they helped the company scale while keeping everyone aligned on direction. OKRs were built for organizations that need alignment at scale. Origins: From Intel to Google
◦ the goal is designed to stretch ◦ If you hit 100% every time, goals are not ambitious enough • The moonshot mindset ◦ not 'can we do this?' but 'what would it take?' Moonshot OKRs: Goals Beyond the Status Quo アジャイルチームによる⽬標づくりガイドブック: 敏捷團隊⽬標設定指南｜OKR 落地與成果導向實踐法
Organizations struggle to maintain shared direction as context shifts. OKRs create a cadence for revisiting and re-aligning on what matters most. Why OKRs Are Needed Now
② Goals = status quo + 10% ③ Reviews = status reports ④ OKR tied to performance ⑤ Set once, then forgotten 5 Common OKR Failure Patterns‒ the Practice of Change is missing.
alone, with good intentions. The team did not achieve it. They said, “That’s an unattainable goal,” and “It doesn’t align with our mission.” Why? Real Story: Goals That Break Teams
“given”, not “chosen”. The team then redesigned their own OKR. From that point, they moved toward it with energy. The difference was not the goal itself — it was who created it and why it mattered to them. Lack of ownership
important questions through high-frequency dialogue Receiving hints for improvement from an objective perspective via concrete feedback Boosting engagement by having achievements recognized ! ♡
of change • Key Results ◦ measure how far the change has gone But the mechanism to make change happen is not inside OKR itself OKRs Are Designed to Drive Change and Learning
way of working. You cannot set a goal that requires transformation and then change nothing about how the team operates. Ambitious Goals Cannot Be Achieved the Same Old Way
the team is always at capacity with current work • Feedback loops are too slow ◦ it takes too long to know if a change worked • Learning doesn't accumulate ◦ individual insights never become org knowledge Three Structural Barriers to Change
• Using specific tools ◦ (Docker, k8s, etc.) • Merging Dev and Ops departments • Automation for its own sake What It Really Means • The ability to continuously deliver and evolve • A practice of Flow, Feedback, and Learning • Culture + Process + Technology combined • An organization's capacity to inspect and adapt Common Misconception vs. What It Really Means
of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity." The core: building an organization that can change continuously. DevOps: The Ability to Continuously Deliver and Evolve
left to right. Deliver value fast and reliably. • The Second Way ◦ Feedback: right to left. Surface problems early. • The Third Way ◦ Continuous Learning & Experimentation: improve as a whole. Three Ways: The Principles of DevOps
First Way: Flow → Reduce lead time. Work in small batches. Eliminate waste. ← The Second Way: Feedback Surface problems fast. Right-to-left. Shorten detection cycles. ↻ The Third Way: Continuous Learning Turn failure into learning. Share knowledge. Culture of experimentation. Retrospective Knowledge Sharing Safe Experimentation Three Ways — The Principles of DevOps
Time — from commit to production • Deployment Frequency — how often you deploy • Failed Deployment Recovery Time — time to recover Software Delivery Instability: • Change Fail Rate — % of deployments causing failures • Deployment Rework Rate (NEW) — % of unplanned fix deploys DORA Metrics: 5 Indicators of Software Delivery Performance
it ceases to be a good measure." Inflating deployment frequency by skipping tests is not improvement. DORA metrics should reflect your desired state — not be chased for their own sake. Using DORA metrics: Goodhart's Law
trust, transparency, and a learning orientation — are as important as technical practices. Without psychological safety, teams cannot run the experiments that DevOps requires. Psychological Safety and DevOps
from commit to production? How long before you get feedback on a change? Knowing your bottleneck is the starting point for DevOps practice. Where is your team's flow bottleneck?
DevOps builds the capability to change in that direction. The results become evidence in the Key Results, which inform the next round of goal setting. The Structure of the Reinforcing Loop OKR DevOps
to change Delivers change & evidence • What to change • Desired future state • KRs = proof of change • How to change • Flow / Feedback / Learning • DORA metrics as KRs OKR × DevOps — The Reinforcing Loop
fix first • Small batches deliver feedback in days • KR movement is visible and acted on continuously • The loop between goal-setting and execution is tight OKR with DevOps
which capability improvements matter • DORA metrics become meaningful KRs • The team knows why they're getting faster • Outcomes guide technical decisions
trying to create, you know which bottleneck matters most. VSM helps make that bottleneck visible. OKR Gives DevOps Direction アジャイルチームによる⽬標づくりガイドブック: 敏捷團隊⽬標設定指南｜OKR 落地與成果導向實踐法
the ability to deliver change continuously and safely. High deployment frequency enables faster hypothesis testing. Fast feedback enables faster learning. DevOps Makes OKR Real アジャイルチームによる⽬標づくりガイドブック: 敏捷團隊⽬標設定指南｜OKR 落地與成果導向實踐法
to weekly' — a capability KR • DORA metrics track an organization's ability to deliver change • Always apply Goodhart's Law — do not chase the metric itself Using Flow Metrics as Key Results
— quality of feedback 'Establish monthly NPS review cycle' — external feedback KRs can define which feedback loops you will build, not just measure Using Feedback Loops as Key Results
OKR check-ins. When KRs are not moving as expected, ask: what did we learn? what will we change? Connecting Learning Cycles to OKRs アジャイルチームによる⽬標づくりガイドブック: 敏捷團隊⽬標設定指南｜OKR 落地與成果導向實踐法
this Objective? • Is there a bottleneck in our flow that blocks progress? • Do we have a fast enough feedback loop to know if it's working? • Is there a mechanism for learning and adapting? The OKR Question: Is DevOps Connected to This Goal?
a number ◦ 'become X' rather than 'achieve Y%' • Delivery capability is continuously improved ◦ flow, feedback, and learning are active • Failure is treated as data ◦ psychological safety enables real experimentation Three Traits of Teams That Run the Loop
reflects customer feedback in our product Key Results 1: Increase deployment frequency from monthly to twice per week 2: Reduce change lead time from 30 days to 10 days or less 3: Conduct user interviews twice monthly Example : Linking Deployment Frequency to an Objective
there a KR that tracks how fast change is flowing? Is there a KR that measures how quickly you get feedback? Is there a KR that shows learning is accumulating? Does your OKR include any DevOps metrics?
different OKRs than 'Why does this matter now, and what would change if we achieved it?' The framing of the question shapes the ambition of the goal. The Quality of Questions Determines the Quality of OKRs
'Why does this matter most right now?' clarifies the Objective's urgency 02 'If we achieve this, what will be visibly different?' makes the Objective concrete 03 'Can we get there with how we work today? If not, what must change?' connects OKR to DevOps
Type Moonshot aspirational, 60‒70% achievement is success — drives breakthrough thinking Roofshot ambitious but achievable — maintains momentum while improving Which to use depends on team maturity, culture, and context — both are valid
will we actually change next?' Use Value Stream Mapping to find the bottleneck. Pick one improvement per sprint. Connect it to a KR. Translating Goals into Action
'What is slowing our flow the most?' • Pick one improvement for the next sprint • Identify which KR that improvement will move Start Small: Where to Place the First Step
this: "DevOps has always taught us to cross walls." In a world of constant change, organizations that can change continuously are the ones that survive and grow. OKR sets the direction. DevOps builds the muscle. Embrace Change: The Ability to Change Becomes Strength
or just report on numbers? Is there a DevOps practice that makes the change possible? Are OKR and DevOps forming a reinforcing loop in your team? Reflecting on Today's Questions
of Change is missing • DevOps is a practice of continuous change — not just tooling • OKR and DevOps form a reinforcing loop that builds an organization's ability to change 3 Takeaways (Summary)
Ship Features Fearlessly
.jpg){kind=avatar}
.jpg){kind=small}
.jpg){kind=avatar}
ikuodanaka
tbpgr
.png){kind=avatar}
yuichirom
timakin
lecre
ottey0525
nozomuiino
suzakiyoshito
loglass2019
nipap
aeterelink
maronpocar12
ks91
katiecoart
greggifford
jnunemaker
watany
cassininazir
speakerdeck
lara
pwiseman
morganepeng
rakko
nwiizo
