Selecting an Agile Approach for Platform Teams

Good to continue from the delivery lifecycle. In the previous lesson, you separated roadmap intent, backlog priority, near-term release planning, and release-readiness decisions. This lesson focuses on the delivery system that governs how work moves once it enters the team: Scrum, Kanban, or a deliberately designed hybrid.

For a platform team, this is not a theoretical choice. A team may need to build a planned AKS onboarding capability while also handling a production certificate issue, an urgent access request, and a security-policy deadline. By the end of the lesson, you should be able to select an approach for such a situation and justify it in terms of demand, risk, flow, stakeholder needs, and delivery outcomes.

---

Start with the work, not the framework label

Teams sometimes begin with, “Should we implement Scrum or Kanban?” A better opening question is:

What kind of demand reaches this team, and what delivery problem are we trying to solve?

Scrum and Kanban share important Agile ideas:

• work is visible and ordered by value or urgency;
• teams learn from feedback;
• work is delivered in small increments;
• progress is inspected rather than assumed;
• improvement is continuous.

They differ mainly in how they organize the flow of work.

Dimension	Scrum	Kanban
Primary organizing mechanism	Fixed-length Sprint with a Sprint Goal	Continuous flow of work
Planning rhythm	Sprint Planning establishes a near-term plan	Replenishment occurs whenever capacity permits
Change during execution	Protect the Sprint Goal; avoid changes that endanger it	Reprioritize and pull the next item as capacity becomes available
Roles and accountabilities	Defined Scrum accountabilities, including Product Owner and Scrum Master	No prescribed roles
Main flow control	Sprint commitment and shared goal	Explicit work-in-progress limits and pull policies
Typical metrics	Sprint Goal achievement, completed work, forecast trends	Lead time, cycle time, throughput, work-item age, WIP
Particularly useful when	A team is developing a coherent product increment	Demand is variable and service work arrives continually

Neither is “more Agile.” The appropriate choice depends on the team’s work system.

A useful network-engineering comparison is planned change versus operational response. A scheduled network refresh, with a coordinated implementation window and a clear objective, benefits from protected focus. A shared operations queue, where incidents and requests arrive unpredictably, needs visible capacity limits and an explicit way to handle urgent work. Platform engineering often contains both kinds of demand.

---

Scrum: protect focus around a meaningful delivery objective

Scrum is most useful when a stable team can concentrate on a connected product problem for a short, fixed period. A typical Sprint might be two weeks, though the duration matters less than consistency and a credible Sprint Goal.

Consider a platform team building a first version of a self-service application landing-zone service. It needs to deliver a coherent usable increment:

• an API or request workflow;
• standard namespace configuration;
• identity and RBAC integration;
• baseline policy validation;
• documentation for pilot application teams;
• operational acceptance evidence.

The work has dependencies and requires frequent stakeholder feedback. A Sprint Goal such as “Pilot teams can request a compliant AKS namespace through the supported workflow” gives the team a common outcome to optimize for. It is stronger than merely committing to a list of unrelated tickets.

In Scrum, the Product Owner orders the backlog, the team selects feasible work during Sprint Planning, and the team inspects results with stakeholders at a Sprint Review. The retrospective then examines how the team can work better. These regular events create an intentional feedback cadence.

Scrum is a strong fit when most of the following are true:

1. The work can be grouped into a coherent increment. The team can describe a usable outcome to achieve within a Sprint.
2. Unplanned interruptions are limited or can be absorbed elsewhere. The team will not routinely abandon its goal for ordinary requests.
3. Stakeholders benefit from regular review points. Product teams or internal customers need predictable demonstrations and reprioritization discussions.
4. The team needs planning discipline. A newer team may benefit from explicit goal-setting, review, and retrospective habits.
5. The work contains uncertainty that needs short learning cycles. Complex implementation work can be inspected every Sprint rather than planned in detail months ahead.

A frequent misunderstanding is that a Scrum Sprint makes all change impossible. The practical constraint is that changes should not undermine the Sprint Goal. If a critical production incident occurs, the team must respond; pretending otherwise is not agility. But if routine requests continually displace planned work, Scrum alone may be hiding a demand-management problem.

What Scrum does not solve automatically

A Sprint board can make tasks visible, but visibility alone does not prevent excess parallel work. A team can start ten stories during a Sprint, finish none, and still claim to be using Scrum. This is where Kanban practices are valuable even within Scrum: WIP limits, aging work-item review, and attention to bottlenecks.

Do not use velocity as a productivity target for comparing individuals or teams. It is at best a local planning signal, and only meaningful where the same team uses a stable estimation approach. Driving it upward as a management target encourages inflated estimates rather than better delivery.

---

Kanban: manage a service as a flow system

Kanban is usually the more natural starting point when a platform team functions as a shared service for many product teams. Its purpose is to make demand, capacity, waiting time, bottlenecks, and blocked work visible.

The central operating rule is simple:

Work is pulled into active stages only when the team has capacity, and only according to explicit policies.

This changes behaviour. Instead of opening every request immediately, the team finishes work already in progress, identifies the constraint, and then pulls the highest-priority eligible item.

The board image contains an important operational idea: work is not merely moved to communicate activity. A card enters a stage because it meets the agreed entry policy, and it leaves when it meets the agreed exit policy.

For example, a platform team’s workflow could have these policies:

Board stage	Example entry condition	Example exit condition
Ready	Request is understood, prioritized, and has an owner	Engineer pulls it when capacity is available
Analyze	Work needs design, dependency, or risk clarification	Acceptance criteria and implementation approach are sufficient
Develop	Design is adequate and WIP capacity exists	Code or configuration is reviewed and tests pass
Validate	Deployable change is available in a suitable environment	Functional, security, and operational checks pass
Release	Release criteria and rollout plan are satisfied	Change is available, communicated, and support ownership is clear

Kanban is especially appropriate for:

• access, onboarding, and environment requests that arrive at irregular intervals;
• incidents, defects, and security remediation;
• platform operational maintenance;
• CI/CD pipeline support and developer-tooling requests;
• work where priorities can legitimately change from day to day;
• teams serving many internal customers with no single shared Sprint Goal.

WIP limits are not targets for keeping people busy

A WIP limit is the maximum number of items permitted in a workflow stage. It is a control against context switching and accumulating queues.

Suppose a six-person platform team has eight items in development, six waiting for review, and five waiting for validation. Everyone may be busy, but the system is not flowing. The right response is usually not to start another item. It is to help work move through the constrained stage:

• swarm on reviews;
• automate a repetitive validation step;
• clarify an external dependency;
• reduce handoffs;
• temporarily stop starting new work.

The two most useful Kanban time measures are:

• Lead time: elapsed time from a customer request entering the system until it is delivered.
• Cycle time: elapsed time from active work starting until it is completed.

For a platform service, lead time answers the stakeholder question, “How long will this request take?” Cycle time helps the team understand its internal delivery capability. Track distributions and trends, not only averages: an average can conceal a small number of severely delayed requests.

Kanban does not mean “no planning” or “no meetings.” It means planning and improvement happen at cadences that suit the service: daily flow review, weekly replenishment, periodic service-delivery review, and regular retrospective improvement.

---

A hybrid approach: Scrum cadence with Kanban flow controls

A hybrid, often called Scrumban, is useful when a platform team has both planned product work and a meaningful amount of interrupt-driven service work.

This is common for a team responsible for an internal developer platform. It may have a quarterly roadmap, a prioritized feature backlog, and several application teams relying on it daily. Pure Scrum can become fragile when urgent operational work repeatedly enters mid-Sprint. Pure Kanban can make it harder to establish focus on a complex multi-week capability such as an Azure landing-zone onboarding experience.

A sensible hybrid preserves only the practices that solve real problems. It is not “we do everything.”

For the self-service landing-zone team, a hybrid model might look like this:

Element	Deliberate operating choice
Planning cadence	Two-week Sprint Planning and a clear Sprint Goal for planned capability work
Board	One visible workflow board shared by feature, defect, and operational work
WIP control	WIP limits in Analyze, Develop, Review, and Validate
Interrupt policy	One expedite lane, limited to a verified production or security emergency
Capacity allocation	Reserve a defined portion of capacity for support, automation, and technical debt
Review cadence	Sprint Review for platform consumers; weekly service-flow review for demand and blockers
Metrics	Sprint Goal achievement plus throughput, work-item age, cycle time, blocked time, and expedite frequency
Improvement	Retrospective actions informed by board data and stakeholder feedback

The key design choice is how unplanned work enters. For example, a team may define three classes of service:

• Standard: normal requests, handled in priority order.
• Fixed date: a regulatory, migration, or certificate-expiry deadline; accepted only when its deadline and impact are understood.
• Expedite: a rare, high-impact production incident or security event. Limit this lane to one item at a time.

If every request is called urgent, the policy has failed. The platform lead must work with stakeholders to make urgency criteria objective and visible.

---

Make the choice using evidence

Rather than selecting a method by preference, assess the team against the dimensions below.

Decision factor	Evidence pointing toward Scrum	Evidence pointing toward Kanban	Evidence pointing toward a hybrid
Demand pattern	Most work is planned before the Sprint	Requests and incidents arrive continuously	Planned roadmap work plus recurring interrupts
Desired outcome	One coherent increment per Sprint	Reliable service and shorter request lead times	Product increments without losing operational responsiveness
Priority stability	Priority is reasonably stable for one to two weeks	Priority frequently changes based on live demand	Most priorities are stable, but exceptions are legitimate
Work type	Feature development with shared discovery and delivery	Support, maintenance, operations, defects, and small requests	Platform product development with shared-service support
Main problem to solve	Lack of focus, goals, stakeholder feedback cadence	Excess WIP, queues, hidden blockers, unpredictable turnaround	Need for focus and flow control simultaneously
Improvement data	Sprint Goal completion and feedback	Cycle time, lead time, throughput, aging work	Both outcome delivery and flow health
Team relationships	One stable product team	A service team serving many requesters	One stable platform team serving product teams

A framework selection should always be treated as a hypothesis. Review it after several weeks using real data:

• Are urgent requests bypassing the system?
• Is work aging in one column?
• Are Sprints routinely failing because of ordinary support demand?
• Do stakeholders have a predictable understanding of when requests will be delivered?
• Is the team finishing work before starting more?
• Are planned platform outcomes still receiving enough capacity?

If the answers show a mismatch, alter the operating policy. Frameworks are meant to expose and improve the system, not to provide a label that the system must defend.

---

Worked platform-team decision

Assume this scenario:

A platform team of eight engineers supports twenty application teams. It is building an internal onboarding platform for AKS, Azure Key Vault, and baseline observability. About 65% of its demand is roadmap work. The remaining 35% consists of access requests, production defects, security findings, and CI/CD support. Two or three items each month are genuinely urgent. Product teams need to see new capabilities demonstrated regularly, while service requesters need credible response expectations.

A defensible recommendation is a hybrid Scrum-Kanban approach.

The justification is not simply that “platform teams use Scrumban.” It rests on the evidence:

1. The roadmap work needs protected focus. A two-week Sprint Goal can coordinate the related identity, automation, policy, and documentation work needed for a usable onboarding increment.
2. The service demand is real and variable. Forcing every request to wait for the next Sprint would produce poor support outcomes and encourage stakeholders to bypass the process.
3. WIP limits protect the system. They reveal whether the constraint is design, peer review, security validation, or release activity.
4. An expedite policy prevents hidden reprioritization. The team can interrupt planned work for verified high-severity events while making the delivery cost visible.
5. Two forms of feedback are necessary. Sprint Reviews validate whether the platform capability helps application teams; flow metrics reveal whether day-to-day service delivery is becoming more predictable.

A short decision statement for leadership could read:

The platform team will use two-week planning and review cycles for roadmap capabilities, combined with a Kanban workflow for all work. We will apply WIP limits to active stages, reserve capacity for operational demand, and allow only verified P1 incidents or critical security events into a single-item expedite lane. Success will be assessed through Sprint Goal achievement, lead-time distribution for standard requests, aging work, throughput, and the frequency of expedited work.

That is a justification. It names the approach, connects it to the operating conditions, establishes controls, and states how effectiveness will be measured.

---

Common selection mistakes

“We have a board, so we use Kanban.”

A board without WIP limits, pull policies, explicit workflow rules, and flow measures is only visualization. It may improve transparency, but it will not necessarily improve delivery.

“We run two-week Sprints, so unexpected work cannot happen.”

Real incidents and security events do happen. The question is whether the team has an explicit response policy and whether interruptions are rare, measured, and visible. Repeated unplanned work is demand data, not an individual failure.

“Hybrid means every ceremony and metric.”

An overbuilt process creates overhead without solving flow problems. Keep only the elements that address an identified need. For example, retain Sprint Reviews if stakeholders need a regular platform demonstration; do not retain them merely because a framework diagram includes them.

“High utilization means high performance.”

In a flow system, keeping every engineer fully occupied often lengthens queues and delays urgent work. Some available capacity is needed for collaboration, reviews, learning, improvement, and genuinely urgent events.

---

Key takeaways

Scrum, Kanban, and hybrid approaches are choices about how a team manages demand and delivery:

• Scrum suits a stable team pursuing a coherent, short-term outcome with a protected Sprint Goal, regular reviews, and retrospectives.
• Kanban suits continuous, variable demand where the central challenge is managing flow, limiting WIP, exposing bottlenecks, and providing predictable service.
• A hybrid approach is often appropriate for platform teams that must deliver roadmap capabilities while responding to operational work. It needs clear policies, not a vague mixture of practices.
• Choose based on demand pattern, interrupt rate, desired outcomes, priority stability, and the team’s dominant delivery problem.
• Justify the choice with explicit policies and measurable evidence: WIP, lead time, cycle time, throughput, aging work, expedite frequency, and outcome delivery.

Next, you will turn stakeholder needs into platform-engineering user stories with testable acceptance criteria. That work becomes much easier once the team has decided how it intends to pull, plan, and complete those stories.