Episode 95 · 2021-08-20 · 29:47 · Original in Finnish
Agile Development and SAFe | Rami Sirkiä | Negotiator 95
Originally published as “Ketterä kehitys ja SAFe | Rami Sirkiä | Neuvottelija 95”
Nitor's Rami Sirkiä has been taking large companies into agile operating models since the Nokia Mobile Phones era, without ever having written a line of code. The episode's load-bearing observation is counter-intuitive: the hardest part of agility is not in the teams but in management, because management no longer gets to launch large programmes and is instead asked what matters today. Sirkiä describes SAFe as a nautical chart rather than a recipe, and stresses repeatedly that it takes no position on release cadence, feedback channels or who does the work — you could in principle run waterfall with SAFe. The conversation covers the limits of the pizza team, the Agile Release Train as a team of teams, the quarterly rhythm of PI planning, DevOps as a shared culture, and flow efficiency in place of utilisation. It closes with advice that runs against his own firm's sales pitch: hire the developers yourselves.
Core theses
- The hard part of agility is management's, not the teams': the shortened planning horizon takes away the large programme launch, which is what leadership had to hold onto.
- SAFe is a chart rather than a recipe — it takes no position on cadence, feedback or staffing, and you could run waterfall inside it.
- Flow efficiency and utilisation are different targets, and optimising the second reliably damages the first.
- A consultant telling a client to hire its own developers is advice against his own firm's interest, which is what makes it worth recording.
Watch and listen
Key moments
- 00:00 — Shortening the planning horizon is the hardest thing for management
- 00:51 — Rami Sirkiä of Nitor, and a father's machine-code background
- 02:43 — The waterfall model, and the agile manifesto's answer to it
- 04:43 — Resources, time, quality, and the cadence of sprints
- 06:11 — The pizza team, and the problem of coordinating many teams
- 07:49 — The Agile Release Train, a team of teams
- 08:48 — SAFe's big picture is a nautical chart for management
- 09:20 — OP's tribe model, and scaling SAFe into a conglomerate
- 10:31 — Lean simplification, and Bosch's three hundred developers
- 12:01 — PI planning and a quarterly rhythm in place of annual planning
- 13:43 — A shared platform: flow efficiency against utilisation
- 15:08 — DevOps is a shared culture and a shared responsibility
- 17:23 — A Release Train does not dictate the release cadence
- 19:15 — How to get business people involved in development
- 22:20 — Nitor Delta, training, and business agility
- 24:22 — Service design brought code closer to the business
- 27:49 — Own capability or outsourced: the insourcing message
- 29:19 — Closing words, and SAFe version 5
Summary
Nitor’s Rami Sirkiä has been taking large companies into agile operating models since the Nokia Mobile Phones era, without ever having written a line of code. The episode’s load-bearing observation is counter-intuitive: the hardest part of agility is not in the teams but in management, because management no longer gets to launch large programmes and is instead asked what matters today. Sirkiä describes SAFe as a nautical chart rather than a recipe, and stresses repeatedly that it takes no position on release cadence, feedback channels or who does the work — you could in principle run waterfall with SAFe. The conversation covers the limits of the pizza team, the Agile Release Train as a team of teams, the quarterly rhythm of PI planning, DevOps as a shared culture, and flow efficiency in place of utilisation. It closes with advice that runs against his own firm’s sales pitch: hire the developers yourselves.
Management loses the big launch
Teams adapt to a two-week rhythm fairly easily. What a shortened planning horizon takes away is management’s largest instrument — the multi-year programme announced with a budget — and replaces it with being asked, repeatedly, what matters this quarter. That is the change organisations actually fail at.
A chart, not a recipe
Sirkiä keeps saying what SAFe does not specify: not the release cadence, not the feedback channels, not who does the work. Taken seriously that means the framework cannot be blamed for a bad implementation and cannot be credited with a good one — it only shows where the rocks are.
Advice against his own sale
The closing recommendation is to hire the developers rather than buy them, from someone whose firm sells them. The reason given is that you are building your own future competitiveness, and the fact that it costs him something is why it belongs on the page.
Watch
The recording lives on the Neuvottelija channel: Ketterä kehitys ja SAFe | Rami Sirkiä | Neuvottelija 95. A Finnish edition of this episode is published at www.neuvottelija.fi.
In depth
The Neuvottelija AI editions carry a long-form write-up of this episode: English · suomeksi.
Go deeper
Explore the ideas in depth
Guides connected to this conversation, with frameworks and further reading.
Enterprise AI Agents: Economics, Governance and the Shift From Tools to Workers
A guide to enterprise AI agents — the real cost model behind agent work, why owning your own stack is becoming a strategic question, a working governance framework with approval gates and audit trails, the agent risk matrix, the EU AI Act timeline as it stands, and who captures the productivity gains. Grounded in a real multi-agent lab, two 2026 keynotes, and Neuvottelija conversations.
Nordic SaaS Valuation & M&A: How AI Reprices Software Companies
How software companies in the Nordics are valued and sold as AI moves inference into the cost of goods sold — where multiples stand in mid-2026, the metrics that get repriced, why vertical SaaS defends its premium, AI due diligence, and the shift from seats to outcomes. Grounded in Translink's SaaS valuation work and Neuvottelija conversations.
People and topics
Guests: Rami Sirkiä