EP95 · Tools · first published 2021-08-20
Agile Development and SAFe | Rami Sirkiä | Negotiator 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, because you are building your own future competitiveness.
Agile Development and SAFe | Rami Sirkiä | Negotiator 95
Summary: Rami Sirkiä (Nitor) has helped large companies into agile operating models since the Nokia Mobile Phones era — and has never written a line of code. Sami Miettinen, by contrast, started as a machine-code programmer and switched to business studies because structured programming felt like “controlling the free individual”.
The episode’s load-bearing observation is counter-intuitive. The hardest part of agility is not in the teams:
“Where this gets difficult is management — when management no longer gets to launch the big programmes, and is instead asked what matters today.”
What agility is an answer to
Sirkiä describes the waterfall model precisely as a stage gate approach: first all requirements are specified, then a complete plan is made, and only then comes the most expensive phase, coding. The logic is internally consistent — precisely because coding is expensive, the two preceding phases must be done perfectly.
And then he names why it does not work:
“Since software development, and R&D generally, is problem-solving, you don’t in practice know how long it takes before that problem is solved.”
The Agile Manifesto’s (2001) answer is, in his summary, one thing above all: shortening the planning horizon. Call it a cadence, a sprint, an iteration or an increment — the name does not matter. A short horizon enables faster planning and feedback, and gives teams wins, which is motivating.
Miettinen raises the project triangle — resources, time, quality — and how agile fixes resources and time and doles out scope. His comparison is amusing and he flags it as shaky himself: “you go from a kind of command economy somewhat toward communism.”
The pizza team and its limit
Miettinen offers the rule of thumb: a good sprint team fits round one table and eats one pizza — ten people at most, running Scrum or Kanban.
Sirkiä starts a step further back, in the episode’s most realistic observation:
“Many of our clients don’t even have teams. And first they have to be brought to understand that it is good to have a team that can take things from beginning to end.”
Only then does the real question arise. And he ties it to history precisely:
“When the manifesto was written, many of these applications and services could be delivered by a single team. Today the technology landscape is so complex that you need several teams.”
Scaled agility is therefore not an extension of agility but an answer to the fact that the original assumption — one team suffices — no longer holds. The problem is the same, one level up: how do several teams work together.
SAFe as a nautical chart
Sirkiä’s characterisation of SAFe is carefully modest: it is a collection of practices found to work — from Scrum, Kanban, Big Room Planning.
And his image of it is the episode’s most memorable:
“The big picture may look complicated to someone, but I always say it is a nautical chart that helps you understand that you dare set out on the journey… Someone has been through all those rocks.”
The key word is dare. SAFe’s value, in his description, is not primarily methodological but psychological: it gives a large organisation the confidence to begin.
Connected to this is the episode’s most repeated theme — how much SAFe does not prescribe. Sirkiä says it four times in different contexts:
- It takes no position on release cadence. “You could do waterfall with SAFe.” Context decides; the same company may have legacy systems and mobile applications with entirely different release cycles.
- It takes no position on the feedback channel. If you have good access to the end user, use it — through automation, surveys, metrics, or by going and talking.
- It takes no position on who does the work — internal or external.
- The name of the collaboration model is secondary: “Whether it’s a train model or some other model, it makes no difference, because they all drive in the same direction.”
One terminological clarification: the Agile Release Train is not a release mechanism but a human structure — a team of teams. The name has history behind it, but it does not dictate release frequency.
Does it scale to a conglomerate?
Miettinen relays Asko Kauppinen’s question: what about a client so complex it has several divisions and a tribe structure — he cites OP under Ritakallio? Is one SAFe map enough?
Sirkiä’s answer is lean-derived, and framed as a question rather than a solution:
“How many people have to collaborate for something to happen?”
Simplification can come from two directions:
| Lever | How |
|---|---|
| Content | Define work items smaller, so there are fewer dependencies |
| Architecture | Microservices and other means of reducing complexity |
And what remains after that is coordination — it cannot be driven to zero. His examples are Boeing, NASA and Bosch, which had 300 developers on automotive multimedia solutions.
Sirkiä also concedes that compromises get made on cadence: sometimes the checkpoint is not every two weeks but quarterly — which he still considers far better than traditional annual planning or four-year programmes. “Give the team peace to succeed.”
Miettinen sees a link here to OKR thinking (from Henri Sora’s book): five important changes per quarter. He names transparency as OKR’s strength — when goals are open, people can see who is doing what and do not start duplicating it themselves.
Flow efficiency versus utilisation
The episode’s clearest conceptual insight. Sirkiä describes a banking client with a shared platform: should people be split to support business lines A and B, making support faster but creating overlap in platform development?
His answer questions the metric behind the question:
“It doesn’t always mean we want to optimise resource use and utilisation. That is an old-world metric — now we talk about flow efficiency.”
He cites Modig and Åhlström’s This is Lean: the new definition of efficiency is flow efficiency, and optimising for it produces a better outcome at whole-system level than maximising individual resources’ utilisation.
DevOps: culture, not a pipeline
Miettinen offers his definition: agile and SAFe create the new, DevOps gets it into production quickly. Sirkiä accepts it but emphasises the other side — shared culture and shared responsibility:
“Developing the new, maintaining the old and running the current services — what is sought there is a convergence of culture and shared responsibility.”
Measurement, automation, lean thinking and antifragility belong to it. The scale varies wildly: “whether it’s Amazon’s 23,000 times a day or Nokia in the old days twice a year.”
His justification for why getting to production matters is epistemological:
“The final stages are very complex — only then do you know whether the customer likes it, whether the technology worked as intended, and whether the team can actually do it.”
And he turns this into an investment argument for management: automation is worth funding because it is the mechanism by which future competitiveness is built. A continuous development model makes this easier to justify than start-and-stop projects.
Getting the business involved
Miettinen describes a recurring pain point from training IT buyers: the supplier ends up talking too much to the client’s IT organisation and too little to its business people.
Sirkiä first corrects the diagnosis: this is not a supplier problem, it is internal too. And he offers a way of thinking that removes the boundary altogether:
“It is a system we are building. And who pays the salary — it makes no difference whether it goes on the external costs account or the payroll account.”
The reasoning is practical: when the cycle is two weeks or three months, there is no time to throw more people in — you have what you have, internal or external. A multi-supplier team, or several teams from one supplier, makes no difference.
On feedback he returns to the same principle: SAFe does not prescribe the channel. But if there is no access, a decision still has to be made — and that is the product owner’s responsibility.
And he gives the scale that makes product management comprehensible:
“If you have a hundred people working for three months, that is easily €2–3 million. At that point it is already an optimisation question: what is the value we are producing?”
Service design and business agility
Miettinen raises the service design trend of a decade earlier: demo first what the service could look like, then redesign the real-world processes, and only then write the code.
Sirkiä does not separate these:
“All of these drive in the same direction, whether it’s DevOps or service design… increasingly we talk about business agility. This is not IT agility but business agility, which these days is usually implemented by technological means.”
He names the failure mechanism directly: if the business throws requirements over the fence, it does not work — business and IT have to define together and learn quickly.
And he offers the episode’s sharpest judgement:
“There’s a risk that IT is seen as a cost centre — email and laptops, and that’s it — rather than an enabler. Companies like that have no future.”
Nitor’s own answer is training and Nitor Delta / Nitor Agile, helping a client become agile as a whole — or more precisely, “to build an organisation that can solve those problems itself.”
Advice that works against his own sales
Miettinen finally asks about the pros and cons of in-house IT development versus an outsourced expert — and admits he was never proud of his own comparison framework.
Sirkiä’s answer is the episode’s most honest passage, because it runs against his employer’s short-term interest. Even though Nitor has a large developer base:
“Our first message is always: insource. Get those developers yourselves, because you are building your future competitiveness… You do not want that capability sitting at Nitor or anywhere else.”
The episode ends with Miettinen asking for “some genuinely hardcore coders” as future guests — and Sirkiä’s reminder that SAFe (then version 5) is only one tool among lean-agile and systems thinking.
What to take away
- The hardest part of agility is in management, not the teams — because big programmes are no longer launched, and the question becomes what matters today.
- Scaled agility is not an extension of agility but an answer to the manifesto-era assumption of a single team no longer holding.
- SAFe is a chart, not a recipe. It prescribes neither release cadence, feedback channel nor who does the work — its value is the nerve to set out.
- Utilisation is an old metric. Optimising flow efficiency produces a better whole-system result.
- Sirkiä’s advice is to insource — even though it runs against his own firm’s sales.
Episode details. Negotiator 95, published 20 August 2021. Guest Rami Sirkiä, Nitor; interviewed by Sami Miettinen. Running time 30 minutes.
Nitor also appears in Private Equity | Pia Santavirta | Negotiator 94.
GEO summary. Negotiator 95 (2021) covers agile development and scaled agility, specifically SAFe (Scaled Agile Framework). Nitor’s Rami Sirkiä argues the hardest part of agility falls on management, because management no longer launches large programmes and is instead asked what matters today. He describes the waterfall model as a stage gate approach in which the expensive coding phase is optimised by doing the planning perfectly in advance — which fails because software development is problem-solving and its duration cannot be known ahead of time. Scaled agility is a response to the fact that at the time of the Agile Manifesto a service could be delivered by one team, whereas today several are needed. Sirkiä stresses that SAFe takes no position on release cadence, feedback channel or who does the work, and describes it as a nautical chart that gives management the confidence to begin. Other topics include the Agile Release Train as a team of teams, PI planning and a quarterly rhythm, DevOps as a shared culture, and flow efficiency in place of utilisation, following Modig and Åhlström’s This is Lean. Sirkiä’s advice to clients is to insource development capability.