Why Is Your Agile Program Still Slow? Many Agile Project Managers struggle to answer this question. Each of your teams works in Sprints. They have Product Owners, Scrum Masters, backlogs, Sprint Reviews, and Retrospectives. Each team meets their Definition of Done each Sprint. Velocity looks reasonably stable.

Yet, when you look at the larger program, something doesn’t add up.

Features still take months to reach customers. Releases are often delayed. Teams frequently wait for each other. Integration becomes a last-minute struggle. A feature that one team completed two Sprints ago is still not in production. I call this a classic “Watermelon Symptom.” Like a watermelon, things look bright and green on the outside. But when you cut open the watermelon (or the project!).  It’s all bright, scary red!!

The individual teams seem Agile. So why is the overall program still slow?

This is a challenge I frequently see in large Agile Programs. We often focus our efforts heavily on making individual teams Agile, while the bigger constraint sits between the teams.

Agile Teams Don’t Automatically Create an effective Agile Program

Imagine an e-commerce company developing a new one-click checkout capability. The Checkout Team finishes the customer interface in a Sprint. But it needs a new API from the Payment Team. The Payment Team, in turn, is waiting for security approval. Once that is complete, everyone needs an integration environment that is currently being used by another release.

Every team may be working efficiently. Each team may be following the Agile Mindset and Scrum Framework. But the customer is still waiting. This is an important mindset shift for Agile Project Managers: local efficiency is not enough to  create end-to-end flow. The real question is not simply, “How quickly is each team completing its work?” It is: “How quickly can we deliver value across the entire system?”

How Can You Improve End-to-End Flow Across Agile Teams?

One common cause of slow program delivery is the way teams are structured. Siloed teams with specialized work type (think a testing team or an API team ) is one of the key causes of delivery Issues in Agile Programs. As per The 17th State of Agile Report 37% of teams dissatisfied with Agile say that siloed teams causing delays in deliverables is  a key reason.

Consider a feature that requires work on the UI, APIs as well as the database. Often the orgs structure their teams around specialized work. This means they will have an independent UI team, database team, testing team and deployment team.

Then in this case usally the work moves like :

UI → API → Database → Testing → Deployment

Each team will be highly skilled and individually productive. But every handoff adds overhead and delay….

The API team may not have capacity when the UI team finishes.  The database team will have different priorities when the API team completes their work. Testing may be committed to another release. Deployment may happen only during specific windows.

This is why large Agile programs need to think carefully about team design, not just Scrum adoption at the individual team level.

Usually, practical, cross-functional Feature Teams that can deliver end-to-end customer value reduce handoff overhead and dependencies. Component, platform and specialist teams will often still be necessary—but smart organizations create those deliberately and thoughtfully rather than simply reflecting existing organizational silos

Why Shared Services Often Become Hidden Bottlenecks

Large programs often need specialist capabilities such as architecture, security, UX, compliance, data science, or infrastructure. These are costly skills. Also, we often do not need them all the time.

Creating shared teams for these skills usually appears efficient in theory.

But imagine ten Agile teams depending on the same security team.

Each delivery team works in two-week Sprints. But the security team works via a centralized queue. Suddenly, supposedly Agile teams are waiting three weeks for a review.

The individual teams are not necessarily the problem. The constraint usually appears at the system level.

Agile Project Managers therefore need to look beyond whether teams are completing their Sprint Backlogs. They need to ask where work queues up, where teams repeatedly wait, and which shared capabilities often become bottlenecks.

How your technology practices often increase Dependencies in your Agile Program?

Organizational structure is just one factor that exacerbates dependencies.  Technology constraints are another major issue.

A team often ends up waiting for another system, API, environment or dataset before they can complete their work.

For example, the Checkout Team is waiting  to test a new digital-wallet option because the Payment API is not ready. An AI team can’t validate its recommendation engine because historical customer data hasn’t been migrated yet.

Simply putting these dependencies on a program board makes them visible. But it does not make them disappear.

Sometimes the better solution is a change in technical approach: API-first development, mock services, automated environment provisioning, reusable components, or a more modular architecture are some of the technological approaches that help withto reduce dependencies.

As an Agile Project Manager, you need to empower your large Agile Projects/ Programs with right technology enablers

How the Metrics you track impact your large program delivery

Another reason slow programs can appear healthy is that we may be looking at the wrong metrics.

Suppose every team’s velocity is stable. Sprint burndowns look good and most teams regularly achieve their Sprint Goals.

Management sees green dashboards.

Yet a customer feature still takes twelve weeks to travel across the organization. – A classic watermelon!

Team-level metrics tell us useful things about individual teams, but they may not expose the delays or bottlenecks between teams.

At the program level, we need different questions (which means different metrics!):

• How long does it take for an idea to reach production?
• Where are the bottlenecks?
• Are queues growing between teams?
• How predictable are our releases?
• Which dependencies repeatedly delay delivery?

Measures such as lead time, Cumulative Flow Diagrams, and release predictability provide a view of program health.

The objective is not to create more metrics. It is to measure what helps us understand end-to-end delivery.

How can you reduce dependencies in your Agile Program?

When programs struggle with dependencies, the natural response is often to improve dependency management.

We create dependency logs, program boards, coordination meetings and design escalation mechanisms.

These are useful. Dependencies must be visible and actively managed.

But there is a more powerful question: Can we remove  this dependency altogether?

Could we create a more cross-functional team?

Could a commonly required capability become a reusable service?

Could we split a large feature into smaller, more independent increments?

Could teams use mock APIs instead of waiting for another team?

Could architecture become more modular?

Could an approval or environment provisioning process be automated?

Good Agile program management doesn’t only coordinate dependencies better. It continuously looks for opportunities to reduce the number of dependencies the organization creates in the first place.

Snehamayee’s View

What Does This Mean for the Agile Project Manager?

This is where the role of the Project Manager changes significantly in an Agile environment.

The Agile PM should not become a person who simply collects status from multiple Scrum teams and combines it into a program report.

Their perspective needs to be broader.

They need to see patterns that individual teams may not see: recurring dependencies, organizational bottlenecks, shared-service constraints, integration risks, vendor delays and program-level flow.

They facilitate conversations across teams, make dependencies visible, escalate systemic impediments and help teams and leaders find ways to simplify the delivery system.

In other words, the Agile PM increasingly moves from managing individual activities to enabling the overall system to deliver.

Why Should You Stop Asking Whether Your Teams Are Agile?

Having ten Agile teams does not automatically give you an Agile program.

You can have excellent Scrum Masters, empowered Product Owners and teams that consistently complete their Sprint Goals—and still have a slow delivery system.

Customers really don’t care how quickly each individual team completes its work.

They want to optimize the time it takes for the whole organization to turn an idea into a usable outcome.

So usually the most useful question for leaders and Agile Project Managers isn’t: “Are our teams Agile?” It instead is:

“How easily does value flow across our teams and reach the customer?”

That is where program agility really begins.

The post Why Is Your Agile Program Still Slow? appeared first on World Of Agile.

In this article, I will address What changes when you AI empower a Product.

When an Agile Professional thinks about AI, it is often as a “productivity enhancer”. We look at AI as something that can reduce our effort. AI indeed does that job. But more importantly, AI is rapidly changing  the products we use every day. For example, search engines summarize answers instead of simply displaying links. Business applications recommend actions instead of just presenting dashboards. Streaming platforms recommend what show you can watch next. Development tools generate code.  And now in addition, AI agents are beginning to execute tasks on our behalf.

It is tempting to look at this as simply another technology shift—similar to moving applications to the cloud or making them mobile-enabled.

But I believe the change is more fundamental.

When we add AI to a product, we don’t just change the technology behind the product. We often need to change entire product behavior

Traditional software was largely designed to follow predefined instructions. AI-empowered products can interpret, generate, recommend, reason, and, increasingly with Agentic AI coming in picture, these products can act.

As Agile Professionals or even Product Specialists, we need to understand how AI-empowered products transition from traditional data crunching and display to understanding impact. Read on the article to understand this shift better

From Executing Commands to Understanding Intent

Traditional software expects users to understand how the application works. The user performs action, and the Product or Software responds

Imagine booking a holiday using a conventional travel application. (Think MakeMyTrip or something similar) You, as the user, have to select a destination, enter dates, apply filters for price and hotel category, compare options, and gradually build your itinerary.

The application is very good at executing the instructions you provide. But it does not customize the itinerary for you.

Now imagine telling an AI-empowered travel application:

“We have five days in Sri Lanka. We enjoy wildlife and history, don’t want long drives and would like two days near a good beach. Suggest an itinerary.”

The user has expressed an intent, not provided a sequence of commands.

The AI needs to interpret that intent, understand the constraints, consider alternatives and generate an appropriate response.

This represents an important shift:

Traditional products ask: “What does the user want to do? / what steps will help the user”

AI-empowered products can increasingly ask: “What is the user trying to achieve?”

With this shift from user actions to user intention, we now need to rethink entire customer journeys rather than simply adding AI to existing screens.

From Deterministic to Probabilistic Behavior

This is another fundamental difference.

Traditional software is predominantly deterministic.

If a banking system is programmed to calculate interest using a particular formula, we expect the same inputs to produce the same output every time. Even if we make a mistake in the formula, the same wrong answer will be displayed every time

We can broadly describe this as:

Input → Rules → Expected Output

Generative AI does not always behave this way.

Ask an AI system to summarize a customer complaint twice, and you may receive two slightly different summaries. Both could be perfectly acceptable.

Ask it to recommend the next best action for a salesperson, and there may be several reasonable answers.

And occasionally, AI hallucinates. This means that the AI may produce an answer that sounds convincing but is simply wrong.

AI product behavior therefore looks more like:

Input + Context + Model → Probable Output

This has a huge shift in product behavior.

For many AI capabilities, we cannot simply ask:

“Did the system produce the correct answer?”

We also need to ask:

“How good was the answer?” (Was the itinerary suitable ?/Was the new show recommended by the streaming service relatable? / Did the AI-based customer agent really help the complainant)

This shift will eventually impact the entire product life cycle. It will change

• How we write requirements. – Now we will have to write requirements that capture how do we know if user intent was met?
• How we test the product.   –
• How we measure quality
• How we decide what is an acceptable range of correctness?
• Last but not least, how do we decide our feature is ready for release?

AI empowered Intent driven products will not be merely right or wrong – we need to find a way to capture if the user intent was fulfilled

From Fixed Expectations to Context-Aware Experiences

For decades, we have designed digital products with fixed expectations. You navigate a certain menu, click a certain button – each time same action happens. This is a fixed expected behavior. We discussed above that Intent makes a key shift from expected behaviors for AI – But Context is an equally important factor to consider

Imagine a project manager opening a portfolio dashboard. With a traditional, fixed-expectations product, she expects to scan each of his 20 dashboards daily. Maybe she even has an alert built in to highlight dashboards with “red” items. But in the end, that alert is based on a fixed set of rules

But when working with an AI-empowered, intent-driven dashboard, instead of examining twenty charts, the manager might ask:

“What has changed since last week, and which three things need my attention?”

For the product to answer well, however, it needs context.

What projects does this person manage? What happened last week? Which risks were previously discussed? What does this organization consider critical? What information is this person permitted to access?

We can now see that context is becoming an increasingly important part of product design.

The quality of an AI experience may depend not only on the model being used but also on what the product Context – What the Product knows, remembers and retrieves at the right moment.

From Providing Features to Providing Intelligent Capabilities

Consider a traditional sales application.

It may provide customer records, reports, dashboards, filters and alerts. These features help a salesperson understand what is happening. And using the information, the salesperson then makes a decision about which customers are likely to turn to a competitor product this month

Instead, an AI-empowered version of the sales application could possibly answer:

“Which of my customers are likely to turn to a competitor product this month and why? What can I do to reduce the impact?

The product is no longer simply retrieving or representing information.

It analyzes information, identifies patterns /trends and/or anomalies , and then recommends possible action.

We can see similar changes across industries.

A traditional HR product stores employee information. An AI capability may help managers identify recurring themes in employee feedback.

A project management product tracks tasks and dependencies. An AI capability may identify emerging delivery risks and suggest possible interventions.

A customer-support product displays previous interactions. An AI capability can summarize the customer’s history and recommend a response.

The conversation when we think about AI products moves beyond: “What features should our product provide?”

To Goes towards “What intelligent capabilities should our product have?”

From Assistance to Increasing Autonomy

AI products are also changing in another significant way: they can increasingly act.

Imagine an expense-management product. If we want to limit AI use to analytics, AI could identify unusual expenses. If we want to go ahead and provide recommendation abilities, AI could explain why an expense appears unusual. It could then recommend an action.

But an AI agent takes this even further. It could potentially investigate supporting documents, contact the employee for missing information, update the case and route it for approval.

The products are now going from providing intelligence to taking coordinated action toward an objective.

The difference between an AI that says “Here is what I recommend” and an AI that says “I have done it” is often the differentiator.

As products move along this spectrum, autonomy itself becomes a product-design choice. We need to decide what action an AI agent should be allowed to take and where we need to insist on human intervention. For example, it may be OK to have AI approve a standard insurance claim, but you may want AI to flag any unusual claims to human or maybe you want all rejections to be vetted by a human.  Going further you may want AI to suggest a possible diagnosis to a physician but never to a lay person.

The decisions on where AI acts and when it recommends… Or even what it can recommend what to whom are now the Product Design decisions

Products Can Now Fail in New Ways

Perhaps the most important shift in behavior appears when AI fails. Traditional software certainly fails. Applications crash, integrations break and calculations contain defects.

But AI introduces different kinds of failure. An AI system may misunderstand a perfectly valid request. It may generate information that doesn’t exist. (Hallucinations!).It may use outdated or inappropriate context. It may make a poor recommendation while sounding extremely confident. An autonomous agent may correctly execute an action that it should never have been allowed to take.

This creates an unusual situation: The software may be functioning exactly as designed, while the product is still producing an unacceptable outcome. Data – availability /correctness and retrieval will now impact a lot of outcomes . With data, we now have to worry about the data security / ethics

Concepts such as trust, uncertainty, boundaries, human oversight and acceptable failure increasingly important product considerations.

Snehamayee’s Perspective – Empowering your product with AI is more than adding an AI patch

The most common way people try to adopt AI is to see how it can make current work more productive. How can AI automate my MoM? Can we use AI write user stories / acceptance criteria or even code for me? How can AI write test cases and analyze test coverage?

A few people go ahead and try to incorporate AI in their products- what they do is to take an existing product and ask: “Where can we add AI?”

People may add a chatbot to their Product. Sometimes they add data summarization or trend analytics. They may even add recommendations. These certainly add value to the product.

But the more interesting question is:“If this product had access to intelligence from the beginning, would we design the product differently?”

Would users still navigate through ten screens? /Would they still analyze the dashboard themselves? /Would they still manually coordinate five different activities?

Or could the product understand their objective, assemble the necessary context, recommend an approach and—with appropriate safeguards—take some of those actions for them?

That is where AI stops being merely another feature and starts changing the product.

And this leads to an important question for those of us working in Agile product development.

If our products are becoming probabilistic, context-aware, adaptive and increasingly autonomous, can we continue building them exactly as we built deterministic software?

• Do our requirements need to change?
• What does “Done” mean?
• How should we test something when there isn’t always one correct answer?
• What new risks should teams consider?

And what does all of this mean for Product Owners, Scrum Masters and Agile teams?

Those are the questions I will explore next. while I do that please refer to this document for the design guideline when we build AI empowered Products

Because when the nature of the product changes, the way we build the product must evolve too.

The post What changes when you AI empower a Product appeared first on World Of Agile.

 Project Management for Traditional, Scrum or Kanban work

PMI says, Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. For best outcomes, we need to vary our Project Management techniques by work type. Traditional work Vs Scrum or Kanban, all require different approaches

When people hear the word “Project Management”, they often think only about creating plans, tracking schedules, managing risks, coordinating teams, and ensuring that projects get delivered successfully. But should every type of work be managed in the same way? I believe that the answer is a clear “No”. Delivering a project with stable, well-understood requirements is fundamentally different from developing an innovative product where the solution emerges through experimentation. Both are different again from operational work where requests arrive continuously. This is why effective project management starts with understanding the nature of the work. Traditional project management, Scrum, and Kanban do not simply provide three different ways of organizing tasks. They address different types of work and therefore Project Management for Traditional, Scrum or Kanban work requires different approaches to planning, risk management as well as progress tracking. The role of the Project Manager changes for each approach.

Understand the Nature of the Work

Traditional project management works well for defined work, where requirements are relatively stable, and outcomes are known upfront. Usually, established practices already exist. Examples could include a server upgrade, hardware rollout, or SAP security patching. Because uncertainty is relatively low, detailed planning is both possible and useful. Scrum is designed to help with Complex or empirical work. When requirements are unstable or not clear, teams cannot know everything at the beginning. In such situations, requirements evolve through feedback. Trial and error helps to iterate to the right solution. Developing an AI-based demand forecasting solution or a new digital product are examples. Instead of attempting to eliminate uncertainty through more detailed planning, Scrum manages uncertainty through short iterations, feedback, inspection, and adaptation. Kanban is particularly useful for flow-based or operational work. Production support, incident management, service requests, and supplier tickets are some examples. In such work, we usually do not have a defined beginning and end. Work arrives continuously, and priorities do change frequently. Fast response to the changing priorities and incoming work is important. Deciding a Sprint Goal becomes quite difficult. The challenge is therefore to keep work flowing smoothly while avoiding bottlenecks and excessive Work-in-Progress (WIP). A simple way to remember the distinction is:

If the work can be is stable and can be predicted, plan it; if you need to learn while doing it, use empiricism; if work continuously arrives, optimize the flow.

Planning as per work type: Traditional, Scrum or Kanban work

Planning is necessary in all three approaches, but the purpose and horizon of planning change. In a traditional project, the primary planning question is: What work must we complete, and how do we deliver it on time and within budget? The Project Manager typically creates a detailed project plan covering scope, milestones, dependencies, resources, schedule, and budget. Tools such as the Work Breakdown Structure (WBS), Gantt charts, and milestone plans support this predictive approach. When we plan for predictive work, focus is on efficiency and optimization Scrum asks a different question: What is the most valuable thing we should build next, and what can we learn? Planning is adaptive and focuses on feedback. In such an environment, planning happens at multiple levels through the product roadmap, Product Backlog, release planning, backlog refinement, and Sprint Planning. Scope can and often does evolve as customer feedback and learning provide new insight. The objective is not simply to deliver everything originally requested, but to maximize customer and business value. When we are working with  flow-based or operational work, the planning  question is: What work should we pull next to ensure smooth flow and meet service expectations (SLA/KPIs)? In the flow based work, we continuously prioritize work based on demand, urgency, available capacity, and service expectations. Kanban boards, WIP limits, service request queues, and classes of service help while planning Kanban kind of work.

Thus, Traditional planning optimizes for predictability, Scrum focuses on planning for experimentation with focus on continuous outcomes and Kanban plans for optimizing the flow and removing bottle necks.

Risk Management: The Risk Itself Changes when work type changes

Risk management also differs as per the nature of the work. Traditional projects primarily face risk of execution not going as per plan. The concern is whether the team manages to deliver the agreed scope according to the plan. Schedule delays, missed dependencies, budget overruns, and scope creep are common risks. Project Managers rely on risk registers, dependency analysis, mitigation plans, contingency reserves, and formal change control. In Scrum, the dominant risk is uncertainty and rapidly evolving requirements. Are we building the right features? Will our customers user our prouduct? What if an assumed technical solution does not work? Scrum reduces these risks through short iterations, prototypes, rapid feedback, backlog reprioritization, and continuous learning. Kanban faces operational risk  . Growing queues, SLA breaches, excessive WIP, capacity constraints, and bottlenecks can quickly affect service. Teams use patterns like WIP limits, SLA monitoring, flow metrics, and bottleneck management.  These patterns help the teams to establish the flow.  

To summarize, Traditional approaches try to predict the risk and then analyze and control it.  Scrum emphasizes on learning based on feedback and then adapting and pivoting as needed. While Kanban focuses on detecting problems quickly, restoring flow, and continuously improving.

Tracking Progress differs for each work type: Are We on Plan, Creating Value, or Flowing?

Perhaps the clearest difference is visible in how progress is measured. In a Traditional project, the key question is: Are we on plan? Measures such as milestone completion, percentage complete, schedule variance, cost variance, Earned Value, SPI, and CPI help compare actual performance against the baseline. In Scrum, the more important question is: Are we creating value effectively? Sprint Goal achievement, working product increments, customer feedback, quality, value delivered, burndown, and velocity can provide useful information. Importantly, completing more work does not automatically mean creating more value. For Kanban, the question is: Is work flowing? Lead time, cycle time, throughput, WIP, work-item age, cumulative flow, and SLA compliance help teams understand whether work is moving efficiently through the system.

Success itself looks different for each work type: Traditional projects emphasize delivering scope, Scrum emphasizes delivering value, and Kanban emphasizes delivering flow.

With Changing work types, The Project Manager’s Role Must Change Too

One major misconception about Agile is that Agile does not need Project managers – well if the work needs managing, we need someone to manage the work. Read this article to understand why we still need a manager in Agile Projects. If planning, risk, and tracking change, the Project Manager cannot operate in exactly the same way either. In Traditional projects, the PM naturally spends significant effort planning, coordinating dependencies, monitoring schedules and budgets, managing risks, communicating status, and controlling deviations from the agreed plan. In an Agile environment, these responsibilities do not disappear—they are redistributed. The Product Owner, Scrum Master, team, technical leaders, and Project Manager may share responsibilities that traditionally sat with one PM. This requires an important mindset shift. Instead of focusing primarily on following the plan, focus on achieving the desired outcome. Instead of controlling change, respond effectively to change. We need to move from managing individual tasks to enable high-performing teams. Rather than measuring activity, we should measure customer value and outcomes. And instead of directing execution, facilitate collaboration and learning.

Snehamayee’s recommendation — Choose the Approach Based on the Work

Project Management for Traditional, Scrum or Kanban work is very different. Which is why, Traditional, Scrum, and Kanban should not be viewed as competing methods where one must always be better than the others. The better question is: What is the nature of the work we are trying to manage?

When work is predictable and well defined, detailed planning and control can provide tremendous value. On the other hand, when the work contains significant uncertainty and learning, Scrum’s empirical approach enables teams to inspect, adapt, and discover better solutions. Lastly in situations where work arrives continuously, Kanban helps teams optimize flow and responsiveness. Great project management is therefore not about rigidly following one methodology. It is about recognizing the type of work in front of us and adapting how we plan, manage risk, measure progress, and lead teams accordingly.

When we work at enterprise level Agile, it becomes important to recognize that often we will need to employ all 3 approaches within same large multi team Agile Project or Program based on what each specific team does – I explore this idea with more depth in World Of Agile Agile PM Skill Badge

The post Project Management for Traditional, Scrum or Kanban work appeared first on World Of Agile.

The Product Manager’s Role in PI Planning

This is a guide to understand the Product Manager’s role in PI Planning. As such, the article will describe what a Product Manager must do during PI planning. Read our earlier article about PI planning preparation to understand how to get ready for the event PI Planning is often described as the heartbeat of the Agile Release Train.  This event is more than a mere planning event. This is the event where the strategy gets validated against the practicalities of delivering realities.

 Product Managers Role in PI planning : The Value Gurdian

Product Managers act as a keeper of Value for the Agile Release Train- (ART). During the PI planning, a PM helps stakeholders and the teams to align, and decide what matters most, and how we will deliver it. This article will not go in depth about the PI Planning structure. This article in scaled agile website describes PI planning structure well. Here, I will talk about how a PM shows up—before and during the event—to make it actually work. Before PI Planning: What a PM must align before Day 1 Most of your impact as a PM happens before PI Planning starts. If you walk into Day 1 hoping alignment will happen in the room, you’re already late. Here I will share a few things you need to get in place early. First, stakeholder alignment. Business, Architecture, and Engineering should not be debating fundamental priorities during PI Planning. You don’t need perfect agreement—but you need enough clarity to move forward towards the intended objective Second, priority clarity. Your “Top 10” features shouldn’t be a vague wishlist. They should reflect real decisions—what makes it in, what doesn’t, and why. When you decide priorities, it is tempting to focus all your energies on the low-hanging fruit. Do not fall for the trap. Make sure to balance new features with Architecture runway. Third, dependencies. If there are known cross-team dependencies, start conversations early. Don’t wait for teams to discover them during breakouts. And finally, trade-offs. Go in with a point of view. If capacity doesn’t allow everything—and it won’t—what gives? Preparation is less about documents and more about decisions.

The Product Managers Core Role  During PI Planning

Once PI Planning starts, your role becomes very visible. At a high level, you need to

• Set the direction through the vision
• Balance priorities against capacity
• Negotiate scope when capacity, skill or dependency issues arise
• Work with stakeholders to get the Business Value (BV) numbers established
• Participating in risk management (ROAM)

What you’re NOT  responsible for is micromanaging team plans. A common mistake is trying to be everywhere and solve everything. That usually creates more noise than clarity. Your role is to anchor the conversation around value—and step in only when alignment is at risk.

Presenting the Vision: What You Must Bring to the Table

The vision presentation at the start of PI planning sets the tone for everything that follows. And it’s easy to get this wrong. Reading through slides won’t cut it. Teams need to understand:

• What are we trying to achieve this PI?
• Why does it matter?
• What are the few things we really care about?

The “Top 10 Features” matter—but not as a list. As a clear signal of priority. If everything sounds equally important, teams will struggle to make decisions later. Also, give guardrails:

• What does success look like?
• Are there constraints teams should be aware of?

  A good vision presentation helps the team with clarity about what they should focus on.

Supporting Teams During Breakouts

Breakouts are where the real planning happens. I have seen that, during the breakouts, many PMs either overstep or disappear completely. Both do not help. The balance is important. You’re there to:

• Explain focus and priority when teams are not clear
• Help negotiate scope as an when needed – This can be because
• Facilitate alignment across Product Owners

  You’re not there to dictate how teams should plan their work.

Participate in Draft Plan Reviews

Draft plan reviews are where the ART leadership (PM /RTE and system architect) first sit down with the teams to discuss the plan. This is not just a status update—it’s your chance to catch issues early. Look at:

• Team-level PI Objectives: Are the team-level PI objectives outcome-focused, or have the team just listed down the sequence of stories?
• Commitment levels: What’s committed vs uncommitted—and why? Have the teams created their commitment only on capacity basis or have they considered uncertainties like skill issues/technical feasibility and dependencies
• Capacity alignment: Are teams overloading themselves? Have they considered day to day overheads

Also, pay attention to dependencies. The ART planning board is your friend here. It helps you see where things might break before they actually do. It is often helpful to start the rough ART planning board in this segment. Don’t just listen to what teams present—look for what’s missing.

 Management Review & Problem Solving: Where PMs Shine

This is usually the most intense part of PI Planning. Plans don’t fit. They don’t look like what we had hoped for. Capacity is exceeded. Dependencies create friction. This is where a skilled and prepared PM makes a difference A good Product manager should come prepared with:

• Trade-off options, not just problems – Talk about what changes and trade offs can help us go closer to our earlier ambitions – be ready with a view on what can move out if something else must come in
• Ideas on how uncommitted work could become committed – what help you need?
• Stay firm on what can not really be done – do not set unrealistic expectations. It is critical to balance Business Urgency with team capacity and technical feasibility
• Champion the Architecture runway – do not lose focus on maintaining a balance with immediate feature value and being ready for what comes next

Assigning Business Value (BV): More Than a Number

Assigning Business Value often becomes a mechanical exercise. It shouldn’t be. This is where you help stakeholders understand what really matters. Once stakeholders really “see” what your teams will be doing – alignment is easy to follow A few things to keep in mind:

• Not everything can be “high value” – encourage stakeholders to show what matters most to them
• Explain Architectural runway  –  help the stakeholders truly sppericiate the impact they will have if teams ignore the runway completely in favor of only immediate value
• Explain Uncommitted objectives are not low priority and team will not be ignoring those—The uncommitted status reflects uncertainty

Use this moment to create shared understanding, not just assign numbers.

Common Pitfalls in PI planning

Some patterns show up very often. Good PMs take care to avoid these. Overcommitment is the big one. Planning at 100% capacity seems efficient—but it rarely works in reality. Plan adequate but transparent buffers to allow for unexpected Another anti-pattern of is to actually plan feature delivery work in the IP iteration – This will quickly kill both innovation and your planning for the next PI Then there’s the silent PM. Being unavailable or disengaged during PI Planning creates confusion quickly. Another one is ignoring architectural runway. It’s easy to deprioritize it in favor of visible features—but the cost shows up later. And finally, over-controlling. Trying to drive every decision slows teams down and reduces ownership. The goal is not control—it’s clarity.

How to be an effective PM during PI planning

Being effective during PI Planning isn’t just about what you know—it’s about how you interact during PI planning First, presence. You don’t need to be everywhere—but you do need to be accessible. Especially in high-risk discussions. Second, knowing when to step in. — Step in when teams are not clear about priorities. If they’re debating execution details—step back Third, reading the room. — Confusion, hesitation, repeated questions—these are signals that something isn’t clear. Fourth bring clarity to management and stakeholders – help them understand trade-offs —Discuss what can and can not be done — explain the need for innovation and architecture  runway Finally comes decision-making. — you will be asked to make a lot of decisions. You won’t have complete information. That’s normal. Some factors to consider are Value , risk , capacity and technical feasibility. Also consider face trade-offs: Short-term delivery vs long-term architecture or Business pressure vs technical reality Sometimes you push. Sometimes you adapt.

Conclusion: Bring enough clarity start execution

At the end of PI Planning, you’ll have a plan. But more importantly, you’ll have a level of alignment. The confidence vote is not about perfection. It’s about whether teams believe in what they’ve planned. Your role doesn’t end here. The plan needs to translate into a living backlog. Priorities need to hold—or be consciously adjusted. PI Planning is not about getting everything right upfront. It’s about creating enough clarity and alignment so that when things change—and they will—teams know how to respond. That’s what good product leadership looks like.  

The post The Product Manager’s Role in PI Planning appeared first on World Of Agile.

Being a Scrum Master for Multiple Teams: Why It Happens, What It Breaks, and How to Make It Work

Being a Scrum Master for Multiple Teams – Is it possible? Can it work? and rather “How to make it work?” – In almost every organization I’ve worked with, this question eventually comes up:

“Can one Scrum Master handle multiple teams?” And more often than not—the answer is already assumed to be yes.

Not because it’s ideal. But because it feels practical… It seems more efficient

Let’s be clear about why this model exists before we jump into whether it works.

Why Organizations Assign One Scrum Master to Multiple Teams

In my experience across large agile transformations, this decision usually comes from one (or more) of these reasons:

1. Budget Constraints

Agile transformations are often expected to be “lean.”

So instead of hiring one  Scrum Master per team, Organizations go for one Scrum Master for 2–3 teams. On paper, it looks efficient.

2. Misunderstanding the Scrum Master Role

This is still very common. Often leadership sees the Scrum Master as:

• A meeting facilitator
• A Jira admin
• A status tracker

Then naturally, they ask – “Why can’t one person handle multiple teams?”

3. “Senior = Can Handle More”

I’ve seen this especially with Senior Scrum Masters or Experienced Developers stepping into SM roles. The logic then becomes: “They’re experienced, so they should handle more teams.”

Experience does increase effectiveness. But it doesn’t multiply time or presence.

4. Mature Teams (At Least Perception of It)

Sometimes the assumption is: “These teams are “doing” Agile for long time now. They don’t need much support.” Sometimes this is true. But many times it’s just… optimistic.

When  Organizations Assign One Scrum Master to Multiple Teams

 – What Actually Happens?

Let me share something I’ve seen repeatedly. I once worked with an organization where one Scrum Master supported three teams.

• Team A was high-performing
• Team B was struggling with dependencies
• Team C was newly formed

Guess where most of the Scrum Master’s time went?

Team C (firefighting)
Then Team B (escalations)

And Team A? -They slowly drifted. Retrospectives became routine … Improvement slowed down ….Small issues went unnoticed

Nothing broke immediately. But growth stalled.

That’s the subtle risk in this model.

Challenges You Should Expect

Despite of all this, it is inevitable that you will have to look after more than one team at a time – Below I will give some challenges you should expect in the situation

1. Context Switching Is Real

Every team has:

• Different stakeholders and Energy
• Different maturity
• Different challenges (geographical distribution / domain complexities / cultural differences /product lifecycle stage.. etc)

Switching between them isn’t just logistical—it is a definite mental stress. And this stress builds up. Slowly but surely.

2. You May Move from Deep Impact to Surface Coverage

When you work with many teams, you run the risk of spreading yourself too thin. Then, instead of:

• Coaching behaviors
• Enabling ownership
• Driving systemic improvements

You may end up:

• Just Attending Events – and this is when the Scrum Events start to turn into mere “ceremonies”
• Focusing on the obvious, on the surface “blockers” – you now lack bandwidth to go deeper to seek and address the true impediments. Read this article to understand how (and more importantly – “why” to differentiate between blocker and impediment. 

3. Your Availability Becomes a Bottleneck

Teams don’t need you all the time. But when they do need you—it’s usually urgent. With multiple teams, you’re often:

• In another meeting
• Context-switching
• Or already overloaded

Slowly the teams start to normalize you being less available to them… and that often leads ti them accepting the waiting game.

4. Impediments Take Longer to Resolve

The real work of a Scrum Master is not in meetings or Scrum Events. It’s in:

• Following through
• Influencing stakeholders
• Removing systemic blockers

And that work suffers when attention is split.

5. Energy Drain (The Silent One)

When you are working as a Scrum master for more than one team, you are running from one meeting to other …

• Daily Scrum for Team  A
• Refinement sessions for Team B
• Reviews for Team C
• Retrospectives  for Team A

The cycle goes on and on without a break. This is where even experienced Scrum Masters start feeling stretched.

What Helps When One Scrum Master Is Supporting Multiple Teams

Scrum Guide says Scrum Master is accountable for helping the Scrum Team become more effective. When you work with multiple teams as a Scrum Master, that expectations will still remain. Below I have given some tips that help

1  Shared Product Context

If there’s one factor that significantly improves the chances of success in a multi-team setup, it’s this:  The teams are working on the same or closely related products. I’ve seen this make a huge difference.

When teams are aligned around:

• The same product
• A shared customer journey
• Interconnected features

The Scrum Master gains leverage:

• Better context retention (less mental switching)
• Stronger stakeholder alignment
• Easier dependency management
• More meaningful cross-team coaching

I once worked with three teams building different modules of the same platform.

Instead of treating them as separate units, we:

• Ran joint backlog refinement for shared features
• Aligned retrospectives occasionally to spot system-level issues
• Visualized dependencies across both teams

The result?

Less duplication
Faster decision-making
And significantly smoother flow

Compare that to supporting unrelated teams (say, one in payments and another in HR systems)—the cognitive load and disconnect are much higher.

So if organizations must assign one Scrum Master to multiple teams, product alignment is a powerful enabler.

2. Shift from “Team Scrum Master” to “System Enabler”

If you try to give equal time to all teams—you’ll struggle. Instead:

• Look for patterns across teams
• Solve problems at the system level
• Reduce recurring issues

This is where Kanban thinking (flow, bottlenecks) becomes incredibly valuable.

3. Be Intentional About Where You Go Deep

Not all teams need the same level of attention.

I usually ask:

• Which team is at risk?
• Which team can self-sustain?
• Where will my effort create the most impact?

Then I adjust accordingly.

4. Build Capability Inside the Team

One of the biggest shifts:

Stop being the center of everything.

Instead:

• Encourage team members to facilitate
• Build ownership of Scrum Events
• Develop internal champions

If everything depends on you—you won’t scale. Remember, as a Scrum Master you are accountable from Scrum Team effectiveness – and you are NOT accountable to do everything yourself

5. Make Retrospectives Non-Negotiable

If there’s one place to invest your energies deeply—it’s for Sprint Retrospectives

Even with multiple teams:

• Make every effort to keep retrospectives meaningful
• Focus on real actionable improvement items
• Follow through on actions

This is where the teams start being more effective.

6. Use Visualization to Your Advantage

Across teams:

• Visualize bottlenecks
• Highlight delays
• Track dependencies

When leaders see the system, conversations change. Teams delivering value is more important  than teams just “doing work”

7. Protect  Your Own Energy and bandwodth Ruthlessly

This is rarely talked about—but critical.

• Avoid stacking heavy sessions back-to-back – if you are not at your best, that will impact the value you bring to the table.
• Create thinking space (not just meeting space)  – create some bandwidth for your self to  just think
• Protect time for actual coaching work

You’re not effective when you’re exhausted.

Final Thoughts On Being a Scrum Master for Multiple Teams….

Being a Scrum Master for multiple teams isn’t about doing more.

It’s about:

• Establishing Synergy
• Empowering Teams
• Enabling systems
• And using context (especially shared product context) to your advantage

When done thoughtfully, this model can actually elevate the Scrum Master role from team facilitator to organizational change agent.

The post Being a Scrum Master for Multiple Teams appeared first on World Of Agile.

Does Agile Need Project Managers? A Reality Check

Introduction: Agile and Project Managers

“Agile doesn’t need Project Managers.” Or “Project Managers are getting obsolete”

I often hear this statement. People often say this with conviction, sometimes with relief, and occasionally with confusion.

Over the last decade or so frameworks like Scrum and Kanban have become more famous. And that brought a shift away from traditional roles. Scrum, in particular, explicitly defines only three accountabilities: Product Owner, Scrum Master, and Developers. Scrum Guide does NOT mention a project manager at all.

And just like that, many organizations concluded: the Project Manager role is obsolete. We do not need Project Managers any longer…..

But is that the right conclusion ? — Or have we misunderstood what Agile is actually trying to change?

I do not plan to defend job titles in this article. Instead, I want to discuss and examine the ground reality. I want to talk about what actually happens in Agile projects beyond theory, certifications, and frameworks.

Where Did This Question Come From?

To understand the confusion, we need to go back to traditional project management.

In a traditional setup, the Project Manager was the central authority. This person was responsible to plan, track, report, manage the risk management, communicate with team and stakeholder and above all ensure value delivery.

With so much to do, project managers often became a bottle neck.

Agile challenged this model.

Instead of centralized control, Agile emphasized:

• Self-managed teams
• Collaboration over hierarchy
• Adaptability over rigid planning

In doing so, Agile (more specifically Scrum) didn’t explicitly include the Project Manager role.

Many interpreted  this as “no need for project managers.”

That’s a dangerous assumption and a myth!

While Agile removed the role as a command-and-control authority, it did not eliminate the responsibilities that ensure delivery.

What Agile Frameworks Actually do Say about Project Management

Now Let’s separate the myth from reality.

We saw that Scrum did not specifically ask for Project Managers

What Does Scrum Say about Project Managers?

Scrum defines accountabilities clearly—and Project Manager isn’t one of them. But Scrum operates at the team level. It assumes a relatively contained environment where a single team can deliver value incrementally.

It does not address:

• Cross-team dependencies
• Complex stakeholder landscapes
• Organizational constraints

Kanban and the Project Manager
Kanban goes even further. It doesn’t mandate specific roles at all. Kanban focuses on evolutionary change, improving  the flow via work visualisation, and limiting work in progress.

But again, it assumes a system where flow can be managed effectively. Someone still needs to ensure alignment, remove bottlenecks, and manage expectations. These days, roles emerge for flow management in kanban. Some common  roles are  the Service Delivery Manager (SDM)(who manages workflow and removes bottlenecks – similar to a Scrum Master), and the Service Request Manager (SRM) (who manages the backlog and prioritizes customer requests – like a Product Owner)

SAFe (Scaled Agile Framework) and the Project Manager

SAFe also does not have a designated role called a Project manager. However,  SAFe does include roles like  the Release Train Engineer, the  Product Manager, and the System Architect.

Question is Why?

Because at scale, coordination and alignment is critical. Dependencies multiply. Stakeholders increase. Complexity grows.

And suddenly, the need for overarching thinking becomes undeniable.

The Reality of Agile Projects on the Ground

In real organizations, Agile projects today rarely operate in isolation. They involve:

• Multiple teams working on shared outcomes
• Dependencies across systems and functions
• Stakeholders with competing priorities
• Pressure to deliver faster, with quality

Now ask yourself:

• Who ensures that all of this comes together?
• Who aligns teams when priorities conflict?
• Who manages risks that span across teams?
• Who communicates with stakeholders beyond the team level?
• Who takes accountability for multi team integrated delivery outcomes?

Self-organizing teams are powerful—but they are not designed to solve organizational complexity on their own.

 So Who Actually Does this Work?

Even in Agile environments, the following responsibilities don’t disappear:

• Stakeholder Management – Aligning expectations, managing communication
• Dependency Management – Coordinating across teams and systems
• Risk Management – Identifying and mitigating delivery risks
• Planning at Scale – Beyond sprint-level planning
• Delivery Accountability – Ensuring outcomes, not just outputs

What happens on ground? These responsibilities are often:

• Distributed
• Unclear
• Or silently pushed onto Scrum Masters, Product Owners, or senior team members

This creates confusion—and sometimes, burnout. Read this article to understand the Scrum Accountabilities and what happens when we ask people to wear multiple hats  

The Emergence of the Agile Project Manager

In many organizations, something interesting happens. The role doesn’t disappear—it evolves. The title may not be “Project Manager” anymore. Instead, the new title can be:

• Delivery Manager
• Program Manager
• Agile Project Manager
• Release Train Engineer

But the essence remains the same:
Someone is responsible to connect the dots.

When you assume the title of an Agile e Project Manager, you do not assume a command-and-control authority.

Instead, you become a

• A Facilitator of alignment
• A Enabler of flow
• A Manager of complexity

and

• An Influencer without formal authority

When Agile Projects Fail Without Project Management

Let’s be honest—many Agile transformations struggle.

Not because Agile doesn’t work, but because critical responsibilities are ignored.

Common patterns include:

• Teams delivering increments that don’t align with business outcomes
• Dependencies causing delays and frustration
• Stakeholders feeling disconnected and dissatisfied
• Lack of clear ownership for delivery risks

In such cases, Agile doesn’t feel empowering—it feels chaotic.

And often, the missing piece is not process—it’s project-level thinking and coordination.

What Makes an Agile Project Manager Different

If Agile still needs project management, then what changes?

Everything.

The Agile Project Manager is not:

• A task assigner
• A status tracker
• A gatekeeper

Instead, they:

• Enable flow, not control work
• Facilitate decisions, not impose them
• Influence stakeholders, not manage them through authority
• Focus on outcomes, not just timelines

It’s a shift from control to alignment and orchestration.

Snehamayee’s Thoughts

So do you need an Agile Project Manager? The answer is: it depends.

You may not need a dedicated Project Manager when:

• You have a single, small, co-located team
• Dependencies are minimal
• Stakeholders are closely aligned

But as complexity increases—

• Multiple teams
• Distributed environments
• High uncertainty
• Organizational constraints

—project-level coordination becomes essential.

Call it what you want, but the capability must exist.

The Bigger Problem: We’re Asking the Wrong Question

“Do Agile projects need Project Managers?” is the wrong question.

The better question is:

Do Agile projects need strong project management capabilities?

The answer is clearly yes.

Organizations don’t fail because they have Project Managers.
They fail because they lack clarity on how the role should evolve in Agile.

Conclusion: A Project Manager for an Agile Project is still relevant – You just have to align the work for Agile Realities

Agile didn’t eliminate the need for project management.

It redefined it.

The role is no longer about control—it’s about enabling alignment, managing complexity, and ensuring delivery in dynamic environments.

Whether you call it a Project Manager, Delivery Manager, or something else doesn’t matter.

What matters is this:

If no one is taking ownership of project-level responsibilities, your Agile setup is incomplete.

Reflection for you:
In your Agile projects today—who is actually handling project-level responsibilities?

The post Does Agile Need Project Managers? appeared first on World Of Agile.