How we work · SAFe
How we work: SAFe, PI planning and your cadence
Most of our enterprise clients run SAFe — the Scaled Agile Framework — where delivery moves to a drumbeat of Program Increments (PIs): planning cycles of eight to twelve weeks in which Agile Release Trains commit to objectives at a PI planning event. North Peak Cloud is built to slot into that cadence rather than fight it: our fixed-scope engagements are sized to land inside a single PI, we join PI planning with the teams who will depend on the work, and we deliver against PI objectives with dependencies declared up front — a consultancy that arrives speaking your operating model, not just your technology.
- —SAFe organises delivery into Program Increments — planning cycles of typically 8-12 weeks — with teams grouped into Agile Release Trains (ARTs).
- —PI planning is the cadence event where the train aligns: objectives committed, dependencies mapped, risks surfaced in one (real or virtual) room.
- —Fixed-scope engagements map cleanly onto a PI: scoped before planning, committed as objectives, delivered inside the increment.
- —External work that ignores the train's cadence becomes the train's dependency problem — so we join the planning, board and system demo rather than orbiting them.
- —You do not need SAFe to work with us — the same discipline (fixed scope, declared dependencies, demo on cadence) serves any operating model.
Why a consultancy should care about your operating model
Plenty of consultancies speak fluent Azure and no fluent you. They deliver on their own rhythm, invoice on their own calendar, and discover your release train's dependencies the hard way — by becoming one. If your organisation runs SAFe, the work of an external partner either lands on your cadence or lands on your teams.
So this page is about how we work, not what we build.
SAFe and the PI, in one paragraph
SAFe — the Scaled Agile Framework — coordinates many agile teams by grouping them into Agile Release Trains (ARTs): long-lived teams-of-teams organised around a value stream. The train moves on a fixed drumbeat called a Program Increment (PI), typically eight to twelve weeks. Each PI opens with PI planning: the event where every team on the train plans in the same (real or virtual) room — committing to PI objectives, mapping cross-team dependencies on the program board, voting confidence in the plan, and leaving aligned. In between, teams iterate, integrate and show working software at the system demo.
Whatever you think of frameworks, the underlying idea is sound: alignment is cheapest when it is bought in one room, on a cadence, rather than negotiated continuously in a hundred meetings.
How our engagements map onto a PI
Our offers are fixed-scope by design — AI Base Camp, the Foundry Accelerator and AI Cost Control are all measured in weeks — and that is deliberate: work that fits inside a single Program Increment can be planned, committed and demoed like any other objective on the train.
In practice:
- Before PI planning — we scope together, so the engagement arrives at planning as a defined objective with a fixed price and timeline, not a vague intention.
- At PI planning — we attend. Our dependencies (access, identities, environments, decisions) go on the program board next to everyone else's, where the train can see them — instead of surfacing mid-increment as surprises.
- During the PI — we deliver on the iteration cadence, join the relevant syncs, and keep our work visible in the same tooling your teams use.
- At the system demo — the work is shown working, integrated, inside the increment it was committed in. A landing zone, an AI use case or a cost programme that demos on the train's cadence is real in a way a slide deck never is.
How we enhance the team of teams
An ART already has developers. What it usually lacks — temporarily — is a specific capability at the moment an objective needs it: the AI foundation nobody has built before, the FinOps discipline nobody owns, the pipeline surgery everyone defers. That is the gap we fill, and the way we fill it matters:
- We take the objective the train can't staff, deliver it inside the PI, and hand it over as code and runbooks — so the capability stays when we leave.
- We unblock, not queue. Our dependencies are declared at planning; where our work unblocks other teams' objectives (a landing zone their features sit on, a pipeline their releases flow through), it is sequenced early in the increment so the train compounds on it.
- We pair and transfer. Engineers from the teams work alongside us where they want the skill — the engagement is also the training course.
- We make the train faster, not longer. The measure of an external partner is whether the ART's own velocity is higher after they leave. Fixed scope and knowledge transfer are how we make that true.
Autonomy, cadence and the platform connection
There is a reason this pairs with our view on shift-left and CI/CD: SAFe gives an organisation alignment at scale, and platform engineering gives its teams autonomy at speed. The failure mode of big-room planning is that delivery still queues behind manual gates afterwards; the failure mode of pure autonomy is a hundred teams sprinting in a hundred directions. Cadence for alignment, automation for delivery — the organisations that move fastest run both, which is why we build the pipelines and guardrails that let PI commitments actually ship inside the PI.
And if you don't run SAFe
Then none of the vocabulary matters and all of the discipline still does: fixed scope agreed before work starts, dependencies declared on day one, progress visible in your tooling, working software demonstrated on a drumbeat. That is simply what professional delivery looks like — SAFe just gives it a shared calendar.
If your next PI has an objective with Azure AI, platform or cost written on it, the best time to talk is before planning, not after. Book a call and we will scope it so it lands on the board ready to commit.
Related: Shift-left & CI/CD, Azure DevOps & platform engineering and Azure consultancy.
Asked and answered.
What is PI planning in SAFe?+
PI planning is the Scaled Agile Framework's cadence-setting event: every eight to twelve weeks, all the teams on an Agile Release Train plan together — committing to PI objectives, mapping cross-team dependencies on a program board, and surfacing risks — so the whole train leaves with one aligned plan for the increment.
How does a consultancy fit into SAFe?+
By behaving like a team on the train rather than a vendor outside it: scoping work before PI planning, attending planning so dependencies land on the program board, delivering inside the increment, and demoing in the system demo. North Peak Cloud sizes its fixed-scope engagements to fit a single PI for exactly this reason.
What is an Agile Release Train (ART)?+
An ART is SAFe's long-lived team-of-teams — typically 50 to 125 people — organised around a value stream, planning and delivering together on the PI cadence. It is the unit that plans at PI planning, integrates continuously and demos as one system.
Do I need to run SAFe to work with North Peak Cloud?+
No. SAFe fluency means we slot into enterprise cadences without friction, but the same habits — fixed scope, dependencies declared up front, demos on a regular drumbeat — serve Scrum teams, Kanban teams and organisations with no formal framework at all.