Jira apps for agile teams

Observability is a crucial aspect of building and maintaining reliable applications, and at Easy Agile, we've dedicated significant effort to making our applications as observable as possible. In a recent talk at Atlas Camp 2025, Ryan Brown, our Staff Engineer, shared our experiences transitioning to Forge and the lessons learned along the way. Here are the key highlights from his talk.

What is observability and why it matters

Observability is about gathering and visualizing enough data to understand the health of your software systems and fix problems when they arise. Unlike traditional monitoring, which tells you what happened and when, observability goes a step further to explain why and how issues occur.

For us at Easy Agile, strong observability has:

• Helped us make better decisions about performance and infrastructure needs
• Drastically improved our customer support by letting us quickly pinpoint issues
• Let us adapt to the reality of modern, distributed applications

As Ryan put it during his talk: "When I was working on applications back in the day, we were running on two, three, maybe four data centers at most. Now we're talking about applications that grow at a global scale with people using them across the globe."

Modern applications are far more distributed than they used to be, with thick frontends becoming as complex as backends. This distribution makes the traditional approach of manually checking a few servers inadequate - we need sophisticated observability solutions to understand what's happening across our systems.

The three pillars of observability

Observability stands on three key pillars:

Metrics

These are the number-based measurements of your software - CPU usage, request times, error counts, and so on. But raw numbers alone aren't very helpful. Context is critical - knowing you have five errors is very different from knowing you have five errors from one specific user on one server over two minutes.

Metrics become particularly powerful when identifying trends over time, so you can pinpoint when performance issues began or correlate changes with system behavior.

Logs

Logs are often the first thing engineers get experienced with when dealing with observability. They provide detailed records of events and are the cornerstone of understanding what's happening in your system. They give more information than metrics alone, capturing not just what happened but details about each event that occurred.

They're richer in information but also generate more data. For example, logs might tell you an error occurred because an API returned a bad response - but that alone still doesn't tell you why the downstream API failed.

Traces

Traces help you understand what's happening across all your systems working together. They track transactions as they flow through various services, showing you exactly what happens when a user clicks a button or performs an action.

"Tracing is surprisingly simple," Ryan explained. "You just have a unique identifier for a transaction that gets shared from one system to the next system to the next system."

Traces are particularly useful when you can expose that identifier to end users when something goes wrong. That ID can show you exactly what happened in that transaction, taking the guesswork out of troubleshooting.

‍

Observability on Connect vs. Forge

Our current Connect approach

At Easy Agile, we've implemented comprehensive observability across our Connect apps.

• Metrics, logs, and traces captured for all our applications
• All this data sent to a third-party observability service to get a centralized view
• Front-end components that also send observability data to the same service

The approach reduces cognitive load on our engineers and gives complete end-to-end visibility into user journeys and what's happening across our systems. For this Ryan recommends that you can use commercial services like Datadog or New Relic, or even open-source options like Signoz.

Transition concerns for Forge

When we first looked at Forge, we had several questions:

• How well would tracing work with Forge's communication model?
• Could we define our own custom metrics?
• Would we be able to collect metrics and logs from both front-end and back-end?
• Could we identify specific user transactions for support purposes?

At the time of our evaluation, Forge functions were the primary compute option available, which raised questions about how standard tracing libraries would work in Forge's unique communication model.

Experimenting with a simple app

Instead of trying to migrate one of our bigger products, we created a simple "Sprint Notes" app to test observability on Forge. This let us:

• Quickly iterate through different Forge topologies
• Keep the experiment focused on observability
• Include all the necessary components (UI, API, database)

We took this app through several stages:

1. Connect on Forge: Running our Connect app through Forge
2. Forge with Remotes: Using two approaches - calling remotes through Forge functions, and calling remotes directly from the UI‍
3. Forge Native: Completely rewriting the app to use Forge functions and entity store

Key findings

Connect on Forge

When running our Connect app through Forge:

• All our existing observability worked without modifications
• Front-end and back-end metrics continued to function as before
• Tracing identifiers propagated correctly
• Logs and metrics didn't appear in the Atlassian Developer Console (which makes sense since we weren't using Forge modules)

The observability story for Connect on Forge is pretty straightforward - it just works. As Ryan noted, "All the existing observability that we had in place on Connect worked just as it did before. There was no big change or issues with what we saw there."

We even experimented with different methods of sending data to our observability service, including using a proxy under our own domain, and everything worked consistently as long as the correct content security headers were set.

Forge with remotes

For Forge with remotes, we found:

• Front-end and back-end observability mostly worked
• We had to set permissions.external.fetch.client to allow sending metrics from the front-end
• Adding these permissions required a major version upgrade
• Metrics didn't capture all API calls, particularly front-end calls to Atlas APIs
• Tracing identifiers weren't exposed to remote callers, limiting end-to-end tracing

"This is a little disappointing... we found that when we did calls to our remotes, Forge would generate tracing identifiers for use on the back-end, but unfortunately those identifiers weren't then being exposed to what was making those remote calls," Ryan explained.

While we could see logs in the Developer Console and some metrics were captured, the inability to propagate tracing identifiers back to callers meant we couldn't achieve full UI-to-database traceability or show transaction IDs to end users without implementing workarounds.

Forge native

With a fully native Forge approach:

• Custom metrics and basic tracing are possible but require significant work
• We needed to implement custom handling with libraries like OpenTelemetry
• UI observability remained similar to the remotes implementation
• We could access correlation IDs through undocumented Forge API features

We managed to create a proof of concept showing traces from Forge functions to our observability service, though implementing complete data store tracing would require additional work.

Recommendations and best practices

Based on our findings, we recommend:

1. Establish observability baselines

Figure out what data you genuinely need instead of collecting everything. Observability services charge by volume, so collecting unnecessary data can quickly become expensive.

2. Use OpenTelemetry‍

It aligns with Forge's internal implementation and provides good standardization. While it may be harder to use than some out-of-the-box solutions, the long-term benefits are worth it.

‍3. Consider an observability proxy

This enables:

• Authentication for incoming metrics
• Adding additional context
• Data redaction for sensitive information
• Decoupling your implementation from specific providers

When combined with OpenTelemetry, this approach means your Forge components don't need to know what observability service you're using, avoiding permission changes if you switch providers.

4. Plan permission updates strategically

Since they require major version upgrades, incorporate them early in your development.

5. Other important considerations

• Major version upgrades are required when adding permissions for observability
• The documentation for exporting logs and metrics is technically correct but easy to misinterpret
• Traces do not automatically propagate back to callers in remote implementations

Final thoughts

Achieving all three pillars of observability on Forge is possible, though it requires different approaches depending on your implementation strategy:

• Connect on Forge works seamlessly with existing observability
• Forge with remotes requires some additional configuration
• Forge native needs more custom implementation

These experiments are being prepared for open source, so stay tuned to Ryan's LinkedIn for updates.

You may be just starting out, or you may have worked with agile methodologies for a while, but we’re sure you can agree that scaling agile in a large organization can be daunting. PI Planning is key to scaling agile, so we’ve developed this guide, along with a practical checklist, to help you run successful planning sessions, and build your confidence for your next scaled planning event.

You'll find the free checklist at the end of this guide.

This guide covers everything from basic concepts to advanced implementation strategies. We'll walk through the essential elements of successful PI Planning, including preparation steps, participant roles, agenda structure, and best practices for both co-located and remote teams. You'll learn how to navigate common challenges, leverage tools like Jira effectively, and ensure your PI Planning sessions deliver maximum value for your organization.

Let’s start with the basics.

What is PI Planning?

PI Planning stands for Program Increment Planning.

PI Planning sessions are regularly scheduled events where teams within the same Agile Release Train (ART) meet to align and agree on what comes next. Teams will aim to align on goals and priorities, discuss features, plan the roadmap, and identify cross-team dependencies.

The goal is to align the teams to the mission and each other. Here are the essential elements of PI Planning:

• 2 full day events run every 8-12 weeks (depending on the length of your increments)
• Product Managers work to prioritize the planned features for the increment beforehand
• Development teams own user story planning and estimation
• Engineers and UX teams work to validate the planning

Why do PI Planning?

PI Planning is incredibly beneficial for large-scale agile organizations. PI Planning enables:

• Communication
• Visibility
• Collaboration

To understand the impact, let’s look at an example of a large organization that hasn’t yet implemented PI Planning. This organization has 250 teams and 6,500 team members. These teams rarely speak to each other, outside of dealing with a critical issue that has forced them to collaborate.

Alignment across these teams happens at the leadership team level, and they have multiple levels of managers in between who cascade information down with varying success. There is a constant battle for resources, budget, and opportunities to work on the most exciting projects.

Their projects have a habit of conflicting - one team would release something and then it would break something in another team’s project.

PI Planning is the first time many big companies get their teams together in a room or on the same call to talk to each other. This is a chance to have important conversations about who is working on what.

Why is this important?

1. When you’re touching a system or a code repository, you need to know how it’s going to impact another team
2. You might need to do some work to enable another team to work on their feature first (and vice versa)

With proper planning and collaboration, teams can get things done more effectively, release with more predictability, and stay on budget.

Business benefits of PI Planning

While we've covered the basic reasons for doing PI Planning, let's dive deeper into the specific business benefits that organizations gain from effective PI Planning implementation:

Improved resource utilization

• PI Planning provides a clear view of team capacity and capabilities across the entire Agile Release Train
• Organizations can optimize resource allocation by identifying and addressing skill gaps early
• Teams can better balance workload across iterations and avoid overcommitment
• Cross-team dependencies are identified upfront, preventing resource conflicts
• Shared resources can be scheduled more effectively across multiple teams

Enhanced risk management

• Early identification of potential risks through collaborative planning sessions
• Creation of a comprehensive risk board during PI Planning helps track and monitor potential issues
• Teams can develop mitigation strategies before problems impact delivery
• Dependencies between teams are mapped and managed proactively
• Regular risk reviews during the PI ensure ongoing monitoring and adjustment

Strategic alignment and decision-making

• Business context presentation ensures all teams understand organizational goals
• Product/solution vision sessions align teams with customer needs and market direction
• Management review and problem-solving sessions enable informed decision-making
• Teams can make better trade-off decisions with a clear view of priorities
• Value streams are visualized and optimized across the organization

Measurable business outcomes

• Improved predictability in delivery through structured planning
• Better customer satisfaction through aligned feature delivery
• Reduced waste and redundancy in development efforts
• Increased speed to market for new features and products
• More effective use of organizational resources and budgets

One source of truth

• PI Planning creates a shared understanding across all teams
• Visualization capabilities help teams see the big picture
• All stakeholders work from the same roadmap and priorities
• Dependencies and commitments are clearly documented
• Progress can be tracked consistently across teams

By implementing effective PI Planning, organizations can realize these benefits while creating a more collaborative and efficient development environment. Regular iteration meetings and ceremonies help maintain this alignment throughout the Program Increment, while quarterly steering ensures ongoing strategic alignment.

All very good reasons to do PI Planning.

What is the goal of PI Planning?

PI Planning is an essential part of the Scaled Agile Framework, a framework that’s designed to bring agile to large companies with multiple teams.

SAFe PI Planning helps teams in the Agile Release Train (ART) synchronize, collaborate, and align on workflows, objectives, releases, and more.

Without PI Planning, teams don’t have structured communication. They may not know what the other teams are working on, which can cause a lot of problems. For example, two teams might be working on different features without realizing there’s a dependency, which could hold up the release or require a significant rework of the code.

The goal of PI Planning is to have all your teams aligned strategically and enable cross-team collaboration to avoid these potential problems.

Now that we’ve covered off the “why”, let’s dig a bit deeper into the “what”. The best way to get a picture of what happens during PI Planning is to take a look at an agenda.

What is a program?

A program is where agile teams are grouped together to form a larger group. This is often referred to as the “team-of-teams” level. In simple terms, a program is a group of agile teams.

When you hear people talking about “team-of-teams” or “scaled agile”, they mean taking agile beyond a single team, and asking more teams to join in.

For example, there might be 4 teams working on a NASA spaceship mission to Mars.

NASA decides they want to see if agile can help these teams do better work. So, to start with, the Oxygen team switches from working with traditional Waterfall project management methods to embracing agile principles.

1. Launch team
2. Food team
3. Oxygen team (Agile)
4. Landing team

After a few months, NASA decides that the way the oxygen team is working is going well, so the remaining three teams similarly adopt more agile methodologies:

1. Launch team (Agile)
2. Food team (Agile)
3. Oxygen team (Agile)
4. Landing team (Agile)

Each of these 4 teams are self-organizing, meaning they’re responsible for their own work.

However, now that these teams are all working in the same way, they can be grouped together as a program.

Once you add in the business owners, product management team, systems architect/engineer, and release train engineer, you have all the roles needed to continuously deliver systems or solutions through the Agile Release Train (ART).

What is a program board?

Program Boards are a key output of PI Planning.

Traditionally, they’re a physical board that’s mounted on the wall, with columns drawn up to mark the iterations for the increment, and a row for each team. Teams add sticky notes that describe features they’ll be working on.

• Feature 1
• Feature 2
• Feature 3

Once all the features are added, they work to identify dependencies (features that’ll affect other features) and mark this up by connecting them with red string.

SAFe program boards don’t have to be physical, though. There are a lot of advantages to using a digital program board like Easy Agile Programs, which integrates directly with Jira. We’ll talk more about how you can use Jira for PI Planning towards the end of this guide.

‍

Equip your remote, distributed or co-located teams for success with a digital tool for PI Planning.

Easy Agile Programs

Free Trial

Who is involved in PI Planning?

The success of PI Planning relies heavily on having the right participants actively engaged throughout the event. While every organization may have slight variations, there are several key roles that are essential for effective planning.

Core team members and their responsibilities

Release Train Engineer (RTE)

The Release Train Engineer serves as the primary facilitator and servant leader for the Agile Release Train (ART). Think of them as the conductor of an orchestra, ensuring all parts work in harmony. The RTE's responsibilities extend beyond just running the event – they work to remove impediments, manage risks, and ensure alignment across teams. Before PI Planning, they coordinate with stakeholders to prepare the event. During planning, they facilitate key ceremonies and help teams navigate dependencies. After the event, they track progress and help teams stay on course toward their objectives.

They help:

• Establish and communicate the annual calendars
• Get everything ready (including pre and post-PI Planning meetings)
• Manage risks and dependencies
• Create Program PI Objectives from Team PI Objectives and publish them
• Track progress towards expected goals
• Ensure strategy and execution alignment
• Facilitate System Demos

As the facilitator for the 2-day event, the Release Train Engineer also presents the planning process and expected outcomes for the event, plus facilitates the Management Review and Problem Solving session and retrospective.

Product manager

A Product Manager’s job is to understand the customers’ needs and validate solutions, while understanding and supporting portfolio work.

Before PI Planning happens, Product Managers take part in the pre-PI Planning meeting, where they discuss and define inputs, objectives, and milestones for their next PI Planning events.

In PI Planning, the Product Managers present the Program vision and upcoming milestones. So that they can manage and prioritize the flow of work, they review the Draft plan and describe any changes to the planning and scope based on the Management Review & Problem Solving session. Once the PI Planning event is over, they use the Program Objectives from the Release Train Engineer to update the roadmap.

Following PI Planning, Product Managers play a critical role in communicating findings and creating Solution PI Objectives.

Product owner

The Product Owners are responsible for maintaining and prioritizing the Team Backlog, as well as Iteration Planning. They have content authority to make decisions at the User Story level during PI Planning Team Breakout sessions.

Product Owners help the Team with defining stories, estimating, and sequencing, as well as drafting the Team’s PI Objectives and participating in the Team Confidence Vote. They’re also responsible for conveying visions and goals from upper management to the team, as well as:

• Reporting on key performance metrics
• Evaluating progress, and
• Communicating the status to stakeholders

Scrum master

The Scrum Master is a servant leader to the Product Owner and Development team, which means they manage and lead processes while helping the team in practical ways to get things done.

They facilitate preparation for events (including PI Planning) and prepare System Demos. They help the team estimate their capacity for Iterations, finalize Team PI Objectives, and manage the timebox, dependencies, and ambiguities during Team Breakout sessions. The Scrum Master also participates in the Confidence Vote to help the team reach a consensus.

System architects and technical leaders

These technical leaders provide critical insights about architectural direction and technical constraints. During PI Planning, they present the architectural vision and work with teams to ensure technical alignment. They help teams understand how their work fits into the broader technical landscape and identify potential technical dependencies or risks before they become issues.

Development team members

Developers, testers, and other technical team members are responsible for researching, designing, implementing, testing, maintaining, and managing software systems, and are active participants throughout PI Planning.

During PI Planning, they participate in Breakout sessions to create and refine user stories and acceptance criteria (alongside their Product Owner) and adjust the working plan. Developers help to identify risks and dependencies and to support the team in drafting and finalizing Team PI Objectives, before participating in the Team Confidence Vote. Their hands-on experience is crucial for creating achievable plans and identifying potential risks or challenges.

Business owners and senior executives

Business Owners and executives play a vital role in connecting team activities to business objectives. They typically kick off the event with the business context presentation, helping teams understand market conditions, competitive pressures, and strategic priorities. Throughout planning, they provide valuable feedback during draft plan reviews and help make important trade-off decisions when needed.

Supporting roles and stakeholders

While not always present for the entire event, several other roles provide valuable input during PI Planning:

Customers and end users

When possible, having actual customers participate can provide invaluable direct feedback and help teams better understand user needs. They might participate in specific sessions rather than the entire event.

Subject matter experts

Depending on the domain, various experts might be needed to provide specialized knowledge during planning. This could include security experts, compliance specialists, or domain experts from specific business areas.

Support teams

Representatives from shared services or support teams often participate to ensure their capabilities and constraints are considered in the planning process. This might include UX designers, DevOps teams, or other specialized groups that support multiple teams.

The key to successful participation is ensuring each role understands their responsibilities and comes prepared to contribute. Organizations should provide clear guidance about expectations and necessary preparation work to help all participants make the most of their time during PI Planning.

When is PI Planning held?

Many companies find that 8-12 weeks (which adds up to 4-6 x 2-week iterations) is the right amount of time for an increment.

Some companies hold quarterly PI Planning, for example:

• Q1 PI Planning: December
• Q2 PI Planning: March
• Q3 PI Planning: June
• Q4 PI Planning: September

However, the timing and frequency will depend on how long each program increment is scheduled to last and may need to accommodate holidays.

The good thing about PI Planning events is that they happen regularly on a fixed schedule, which means you can plan for them well ahead of time. That means teams and Business Owners have plenty of notice to ensure they can show up for the event.

This means that what happens in preparation for PI Planning can be just as important as the event itself.

What is a pre-PI Planning event and when is it needed?

A pre-planning event - separate to PI Planning - is to make sure that the ART is aligned within the broader Solution Train before they do PI Planning. It’s all about synchronizing with the other ARTs to ensure the solution and organization are heading in the right direction, together.

You’ll need to organize a pre-PI Planning event if you’re operating at the Large Solution, Portfolio, or Full SAFe levels. Essential SAFe is more basic and does not have a Solution Train, so if you’re operating at this level, you won’t need pre-PI Planning so formally.

Here are a few of the roles that should be invited to the pre-planning event:

• Solution Train Engineer
• Solution Management
• Solution Architect/Engineering
• Solution System Team
• Release Train Engineers
• Product Management
• System Architects/Engineers
• Customers

They’ll look at the top capabilities from the Solution Backlog, Solution Intent, Vision, and Solution Roadmap. It’s really a lot like PI Planning but at a higher level, across the overall solution and not just the individual ART.

The event starts with each ART summing up their previous program increment and accomplishments to set the context. Next, a senior executive will brief the attendees on the current situation before Solution Management discusses the current solution vision and any changes from what was shared previously. Other things that are often discussed or finalized include:

• Roadmaps
• Milestones
• Solution backlogs
• Upcoming PI features from the Program Backlog

How to prepare for PI Planning?

Success in PI Planning starts with thorough preparation. Well before the event, organizations need to focus on both organizational and content readiness. The Release Train Engineer typically leads this preparation effort, working with various stakeholders to ensure everything is in place.

Organizational readiness involves ensuring the right people can participate effectively. This means:

• Setting clear expectations with all participants about their roles and responsibilities during the event. Business owners and stakeholders need to block their calendars and prepare their contributions. Teams need to understand what they'll be expected to deliver during the sessions.
• Arranging appropriate facilities or technical infrastructure for the event. For co-located events, this means securing adequate space for big room planning and team breakouts. For remote events, it means testing collaboration tools and ensuring everyone has proper access. Make sure that the tools you need to facilitate planning are available and working properly. Be sure to test any tech that you are relying on ahead of time (including audio, video, internet connectivity, and access to PI Planning applications), to ensure that your distributed teams can participate in the PI Planning event. Don’t forget to plan for enough food for everyone, too (planning is hungry work).

Content readiness is equally crucial. Here's how each key stakeholder needs to prepare:

• Product Management works on refining the program vision and feature priorities, ensuring they can clearly communicate what needs to be built and why.
• System Architects prepare to share their technical vision and any architectural considerations that will impact planning.
• Business owners gather relevant market and customer insights to share during the business context presentation.
• Teams review their current work and capacity to prepare for planning discussions.

Any presenters will also need to get content ready for their presentations.

What should be included in the PI Planning agenda?

Here’s a standard PI Planning agenda template:

‍

The success of PI Planning heavily depends on careful scheduling and a well-structured agenda. While the standard two-day format provides a framework, understanding the purpose and flow of each session helps teams maximize their planning effectiveness.

Day one: Setting context and initial planning

The first day begins with the business context presentation, typically delivered by senior leadership. This crucial session sets the tone for the entire event, providing teams with insights into market conditions, customer feedback, and organizational priorities that will influence their planning decisions.

Following this, the product vision presentation takes center stage. Product Management shares their roadmap and vision, highlighting key features and priorities for the upcoming program increment. This session helps teams understand not just what they'll be building, but why it matters to customers and the business.

The architecture vision comes next, where technical leaders outline any significant architectural changes or considerations that teams need to account for in their planning. This might include platform updates, security requirements, or technical dependencies that could impact development work.

The afternoon focuses on team breakouts, where individual teams begin their detailed planning work. During these sessions, teams:

• Review their capacity and capabilities
• Begin breaking down features into stories
• Identify initial dependencies with other teams
• Start drafting their plans for the increment

The day concludes with a draft plan review, where teams present their initial thinking to the broader group. This first look helps surface any major conflicts or concerns early in the process.

Day two: Refinement and commitment

The second day begins with planning adjustments based on feedback from day one's draft review. Teams use this time to resolve identified conflicts and refine their plans based on newly discovered dependencies or constraints.

During the morning team breakouts, teams:

• Finalize their feature estimates
• Resolve remaining dependencies
• Complete their team objectives
• Address any identified risks

The afternoon focuses on final plan review and risk assessment. Each team presents their completed plans, now with greater detail and confidence. The group collectively reviews the program board, examining cross-team dependencies and potential risks to delivery.

The day culminates in the confidence vote, where teams indicate their level of confidence in achieving the planned objectives. If confidence is low, teams may need additional time to adjust plans before finalizing commitments.

Keys to successful agenda management

Effective PI Planning requires careful attention to timing and preparation. Organizations should:

• Schedule the event well in advance to ensure key stakeholders can attend. This is especially important for distributed teams who may need to arrange travel or coordinate across time zones.
• Share the agenda and expectations before the event so teams can come prepared. This includes distributing any pre-reading materials or data that teams will need to reference during planning.
• Build in buffer time for unexpected discussions or problem-solving sessions. While it's important to keep to the schedule, some flexibility helps teams address critical issues as they arise.
• Include regular breaks to maintain energy and focus throughout the two days. Big room planning can be intense, and teams need time to process information and recharge.

Remember that while this agenda provides a framework, you may need to adjust it based on your organization's specific needs. Distributed teams, very large ARTs, and other factors might require you to be creative with the schedule. Some sessions may need more time, while others can be shortened. If you have teams in multiple time zones, your PI Planning agenda may need to go over 3-4 days. If it’s your first PI Planning event, try the standard agenda, get feedback from your teams, and experiment with different formats next time.

What happens in the first part of the PI Planning meeting?

The first part of the PI Planning meeting is designed to set the context for the planning that happen next.

Day 1 usually kicks off with a presentation from a Senior Executive or Business Owner. The agenda allows an hour to talk about the current state of the business. They highlight specific customer needs, how the current products address these needs, and potential gaps.

After that, the Product Management team will share the current vision for your product or solution. They’ll talk about any changes that have occurred since the last PI Planning session (usually around 3 months prior). They’ll describe what’s coming up, including milestones and the next 10 features that are planned. This session should take around 1.5 hours.

Why is a confidence vote held at the end of PI Planning?

The confidence vote is a seemingly small but very important part of PI Planning towards the end of the event.

It is important the team is confident in committing to the objectives and work that is planned. The Release Train Engineer will ask teams to vote on this.

Everyone participating in planning needs to vote. This could be via a raise of hands (and fingers) or it could be via the tool you’re using. For example, the Team Planning board in Easy Agile Programs allows each team member to enter their confidence vote.

If the average vote across the room is at least three out of five, the plan is a go-ahead. If it’s less it’ll need reworking (until it reaches a high confidence level). If anyone votes just one or two, they’ll have the chance to share their reasoning.

The confidence vote is all about making sure that the attendees are in alignment and that they agree that the plan in its current form is possible within the given timeframe. Speaking of timing, let’s talk about how and where PI Planning actually fits into your company calendar.

What happens after PI Planning?

After the intensity of PI Planning, the real work of implementing and refining the plans begins. The period immediately following PI Planning is crucial for maintaining momentum and ensuring the plans translate into effective action.

Planning retrospective

Just as teams hold retrospectives after sprints, conducting a thorough retrospective after PI Planning helps improve future planning events. The Release Train Engineer typically facilitates this session, bringing together key participants to reflect on the planning process. Teams discuss:

• What went well
• What went not-so-well
• What could be better for next time

This might include insights about preparation work, team breakout effectiveness, or technical setup for remote participants.

There will also be a discussion of what happens next, which can include things like:

• Transcribing the objectives, user stories, and program board into your work management tool (like Jira)
• Agreeing on meeting times and locations for daily stand-ups and iteration planning

The RTE captures these lessons learned and works with the teams to implement improvements for the next PI Planning event.

Refining and finalizing plans

While teams leave PI Planning with committed objectives, some refinement work often remains. Teams use the days following PI Planning to:

• Fine-tune their story backlogs based on the final agreements made during planning. Product Owners work with their teams to ensure stories are properly groomed and ready for the first iteration.
• Update the program board to reflect any final adjustments made during the confidence vote and closing discussions. The RTE ensures all dependencies are properly documented and visible to affected teams.
• Document and communicate any risks or issues identified during planning that need ongoing monitoring or mitigation.

Integration and alignment

The post-PI Planning period is vital for ensuring all pieces fit together coherently. Teams focus on:

• Synchronizing their iteration plans with other teams they have dependencies with, ensuring their delivery schedules align with the needs of other teams.
• Setting up regular integration points and collaboration mechanisms to maintain alignment throughout the PI.
• Establishing clear communication channels for managing dependencies and sharing progress updates.

Action item follow-through

The success of PI Planning ultimately depends on how well teams follow through on their commitments. Key activities include:

• Assigning owners to action items identified during planning and establishing timelines for completion.
• Setting up tracking mechanisms for cross-team dependencies and risks identified during planning.
• Creating or updating team working agreements to support the new PI objectives.

Ongoing collaboration

As teams begin executing their plans, several mechanisms help maintain alignment:

• Regular sync meetings: Teams with dependencies establish regular touchpoints to stay aligned and address any emerging challenges.
• Program board reviews: The RTE facilitates regular reviews of the program board to ensure dependencies remain on track and identify any needed adjustments.
• Inspect and adapt events: Throughout the PI, teams participate in structured events to review progress, address impediments, and make necessary adjustments to their plans.

Communication and visibility

Maintaining clear communication channels after PI Planning is crucial. Teams should:

• Share finalized plans and objectives with all stakeholders, ensuring everyone understands their commitments and dependencies.
• Establish regular reporting mechanisms to keep stakeholders informed of progress and any significant changes to plans.
• Create visibility around key milestones and integration points to help teams stay focused on their commitments.

The post-PI Planning period sets the tone for the entire Program Increment. By paying careful attention to these activities, organizations can maximize the value of their PI Planning effort and increase their likelihood of achieving their objectives.

The other thing that usually happens after PI Planning events is a post-PI Planning event.

What is a post-PI Planning event?

These are similar to the pre-PI Planning events we looked at earlier. A post-PI Planning event brings together stakeholders from all ARTs within the Solution Train to ensure they’re synchronized and aligned.

Post-PI Planning happens after all the ARTs have completed their PI Planning for the next increment. They present the plans, explain their objectives, and share milestones and expected timelines.

Like PI Planning events, post-PI Planning involves using a planning board, but rather than features, it outlines capabilities, dependencies, and milestones for each iteration and ART. Potential issues and risks are identified, discussed, and either owned, resolved, accepted, or mitigated. And similar to regular PI Planning events, plans go through a confidence vote to ensure they meet the solution’s objectives, and are reworked until the attendees average a vote of 3 or more.

PI Planning in SAFe

If you’re adopting SAFe for the first time, chances are it will start with PI Planning. That’s because it forms the foundation of the Scaled Agile Framework.

As Scaled Agile says, "if you are not doing it, you are not doing SAFe."

SAFe or the Scaled Agile Framework™ is a series of guidelines and practices designed to help bring agility into larger organizations, across all teams and levels of the business. The framework is geared at improving visibility, alignment, and collaboration and should lead to greater productivity, better results, and faster delivery.

Whether you’re adopting all 5 levels or just essential SAFe, the foundation of your transformation and the driver for everything is the PI Planning ceremony.

Scrum and Kanban are also agile frameworks (that you may be more familiar with), and these have historically been very effective at the individual team level. SAFe helps to scale agility across teams; to have multiple teams come together to work on the same products, objectives, and outcomes. It goes beyond the team level to include every stakeholder, outlining what should happen at each level of the organization to ensure that scaled planning is successful.

The purpose of SAFe is to improve the visibility of work and alignment across teams, which will lead to more predictable business results.

This is increasingly important for organizations as they respond to changing circumstances and customer expectations. The traditional waterfall approaches fall short because they’re slow and inefficient.

Bigger companies (often with thousands of developers) can’t keep up with the innovation of smaller, more nimble startups. Along with bigger teams, larger organizations often have stricter requirements around governance and compliance, making it more complex to launch a new feature and deliver new value to customers.

These companies are looking for new ways to organize people into projects and introduce more effective ways of working that use resources more effectively and provide more predictable delivery. If they don’t, they may not survive.

SAFe is a way for these companies to start moving in a more agile direction.

PI Planning is a vital element of SAFe. It’s a ceremony that brings together representatives from every team to help them work together, decide on top features to work on next, identify dependencies, and make a plan for the next Program Increment. As a result, there’s greater visibility across all the teams, changes are made more frequently, and teams work with each other - not against each other. From there, these massive companies can speed up their processes, work more efficiently, compete with newer and more nimble companies, and stay viable.

SAFe and PI Planning are powerful enablers for organizational agility.

While SAFe is a framework designed for larger organizations, there isn't a reason stopping smaller companies from doing a version of PI Planning, too. All you need is more than one agile team to make it worthwhile.

PI Planning in Scrum

You can also use PI Planning as part of a simple Scrum approach.

Scrum Framework diagram shows when and how scrum teams can implement PI Planning

Source: Scrum.org

Scrum is an agile framework that helps teams get things done. It’s a way for teams to plan and organize their own work and tackle user stories and tasks in smaller time boxes. This is often referred to as a sprint.

If multiple scrum teams want to work better together (but aren’t necessarily operating within SAFe), they could adopt a version of PI Planning.

For example, these scrum teams could:

• Meet every 10 weeks and discuss the features they are planning to work on
• Get product managers to combine backlogs and prioritize together
• Share resources across the teams, as needed
• Map dependencies and coordinate joint releases

The good news here is that there’s no “one size fits all” approach to PI Planning, so think about how you could adopt the ideas and principles and make it work for your organization and context.

What is the difference between a PI Roadmap and a Solution Roadmap?

There are different types of roadmaps in SAFe, so it’s important to understand the differences and what each roadmap is meant to do.

PI Roadmap

A PI Roadmap is created before your PI Planning event and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:

1. The current increment (work that’s committed)
2. The next forecasted increment (planned work based on forecasted objectives)
3. The increment after that (further planned work based on forecasted objectives)

Quarterly PI Planning will outline around 9 months of work. The second and third increments on your PI Roadmap will likely change as priorities shift, but they’re still an important part of the roadmap as they forecast where the product is headed next.

Solution Roadmap

The Solution Roadmap is a longer-term forecasting and planning tool for a specific product or service.

It will usually cover a few years at a time, with more specific details available for year one (like quarterly features and capabilities), and more general information (like objectives) for year two and beyond.

‍

Do you have a key role in PI Planning? See how the right tool can help you manage your release train or program better.

Watch an Easy Agile Programs product demo

‍

Remote or hybrid PI Planning

PI Planning in person was once standard, but with teams more likely to be distributed, gathering everyone at the office isn't always feasible. This doesn't have to be a barrier.

The most important principle is to ensure that the teams who are doing the work are able to be 'present' in the planning in real-time, if not in person.

This may require some adjustments to the agenda and timing of your planning, but with forethought and support from the right technology, your PI Planning will still be effective.

Tips for remote PI Planning

Remote PI Planning is ideal for organizations with distributed teams or flexible work arrangements. It’s also a lot cheaper and less disruptive than flying folks in to do PI Planning every few months. If you have the right tools and technology, you can run PI Planning and allow everyone to participate, whether they’re in the same room or on the other side of the world.

Here are a few tips for remote PI Planning:

Embrace the cloud

Use online shared planning tools to allow your team to access and interact with information as soon as possible - ideally in real-time. Ensuring that all participants have instant access to the information simplifies the process of identifying dependencies and maintaining a centralized point of reference for your planning. This helps prevent errors that arise from working with different versions and transferring data between sources.

Livestream the event

Live-streaming audio and video from the PI Planning event is a viable alternative to in-person planning. Actively encourage your remote team members to use their cameras and microphones during the event. While it may not fully replicate the experience of having them physically present, it does come remarkably close.

Record the PI Planning event

Ideally, everyone will participate in the PI Planning live. But if your teams are distributed across multiple time zones or some team members are ill, it’s a good idea to record the event. Having a recording to refer back to could also be useful for attendees who want a refresher on anything that has been discussed.

Be ready to adapt

Some teams will change the standard PI Planning agenda to fit multiple time zones, which could mean starting the event earlier or later for some, or even running it across 3 days instead of 2.

Set expectations

A common issue that can arise from having distributed teams tune in remotely is too much noise and interference. Before your first session kicks off, communicate about when it’s acceptable to talk and when teams need to use the mute button. That way, your teams will avoid getting distracted, while still ensuring everyone can participate.

For more tips, check out our blog on how to prepare for distributed PI Planning.

Whether distributed or in person, if your team gets PI Planning right, it makes everything in the upcoming increment so much easier.

📣 Hear how PNI media have embraced virtual PI planning

Common PI Planning mistakes

PI Planning doesn’t always run smoothly, especially the first time. And the framework itself may present a challenge to some organizations. Here are some common mistakes and challenges to keep in mind (and avoid):

Long, boring sessions

Avoid starting your PI Planning event with long sessions filled with dense content. Think of creative ways to make these sessions more engaging, or break them into shorter sessions. Consider different formats that help to involve and engage participants. And be sure to make room for team planning and collaboration.

Tech issues

Any event is vulnerable to technical mishaps, but if you’re streaming audio and video to a distributed team, this can really impact the flow of the event. It’s a good idea to carefully test all the equipment and connections ahead of time to minimize potential problems.

Confidence vote

Some PI Planning participants struggle with the confidence vote concept. People may feel pressure from the room to vote for a plan to go ahead, rather than speaking up about their concerns. Failing to address issues early only increases the risk of something going wrong during the increment.

Time constraints

When you have a large ART of 10 or more teams, there are a lot of draft plans to present and review, so less time is allocated to each team. Chances are that the feedback will be of poorer quality than a smaller ART with 8 teams.

Not committing to the process

PI Planning isn’t perfect and neither is SAFe. However, the process has been proven to work for many organizations, when the organization is committed. Start with the full framework as recommended; you can adapt the framework and your PI Planning event to suit your organization, but be sure to commit to the process that follows. Anything that is half-done will not deliver full results.

Sticking with the same old tools

If something is not working, fix it. For example, too many teams stick with traditional SAFe Program Boards even though they’re not always practical. If the post-it notes keep escaping, the data entered into Jira seems incorrect, or you have a distributed team who want a digital way to be part of your PI Planning event… it’s time to upgrade to a digital program board like Easy Agile Programs.

Ready to implement PI Planning in your organization? We've created a checklist to help you get started.

Free PI Planning checklist

Effective PI Planning requires careful coordination. This checklist outlines the essential steps, from pre-planning activities to post-event follow-ups, ensuring nothing gets overlooked.

FREE DOWNLOAD

It includes:

• Event Preparation – Logistics, tools, and content setup
• Pre-PI Planning – Key activities to align stakeholders
• Day 1 & Day 2 Agendas – A structured breakdown of sessions
• Role-Specific Responsibilities – Clear guidelines for each participant
• Remote/Hybrid Considerations – Tips for distributed teams
• Post-PI Planning Actions – Steps to keep momentum going

Download your PI Planning Checklist for free.

Once you have your checklist and process in place, you'll want to consider the right tools to support your PI Planning sessions. We might be biased, but think Easy Agile Programs + Jira is your best bet.

Using Jira for PI Planning

Jira is the most popular project management tool for agile teams, so chances are you're already using it at the team level.

When you need to scale team agility as part of an ART, it can be difficult to properly visualize the work of multiple teams in Jira. The only way you can do that in the native app is by creating a multi-project board, which is rather clunky.

Traditional PI Planning on a physical board using sticky notes and string may achieve planning objectives for co-located teams, but what happens next? After the session is over, the notes and string need to be recreated in Jira for the whole team so that work can be tracked throughout the increment. This is a cumbersome and time-consuming process that is open to error as sticky notes are transcribed incorrectly, or go missing.

The best way to use Jira for PI Planning is to use an app like Easy Agile Programs to help you run your PI Planning sessions. The integrated features mean you can:

• Set up a digital Program Board (no more string and sticky notes!)
• Do cross-team planning
• Visualize and manage cross-team dependencies, create milestones
• Identify scheduling conflicts to mitigate risks
• Get aligned on committed objectives for the Program Increment
• Visualize an Increment Feature Roadmap
• Conduct confidence voting
• Transform Jira from a team-level tool to something that’s useful for the whole ART

Join companies like Bell, Cisco, and Deutsche Bahn who use Jira to do PI Planning with Easy Agile Programs (from the Atlassian Marketplace).

Looking for a PI Planning tool for Jira?

We’ll continue to revisit this guide in the future. If you have any questions about PI Planning or you notice there’s an aspect we haven’t covered yet, send us an email 📫

The days of 'doing Agile' are over. As we enter 2025, organizations’ relationship with agility continues to evolve.

Economic pressures, technological advances, and hard-learned lessons are pushing organizations to rethink their approach to agility. While many companies still struggle with meaningful transformation, clear patterns are emerging that signal where agile practices are headed this year.

Drawing on insights from Agile experts and practitioners, here are eight key trends that we see defining how we work this year.

1. The Return to Agile Fundamentals

Key Highlights:

• Movement away from heavyweight frameworks back to core Agile principles and values
• Emphasis on simplicity and delivering customer value rather than ceremonial processes
• Integration of Agile practices into daily work without drawing attention to them

While large organizations continue to rely on structured frameworks to drive consistency across teams, we're seeing a growing groundswell of support for getting back to basics. This isn't about abandoning structure entirely - it's about finding the right balance. 

Teams are increasingly focused on streamlining processes, embracing continuous improvement, and maintaining an unwavering focus on delivering real customer value.

The pendulum is swinging back from scaled frameworks to fundamental engineering practices. Teams are incorporating agile practices into their daily workflows without the overhead of excessive ceremonies. Delivering with feature toggles, continuous integration, and trunk-based development are becoming more important than analysing burndown charts and a calendar full of unproductive ceremonies.

Expert take:

“Rather than telling people how to do their jobs, work with them to set the goals for a process that would make them and the company more successful. Measure success based on improved team behavior rather than adherence to a set of rules. Instead of Agile, push for agility. In that sense, Agile is never really over. It’s just transforming into what it should have always been.” 

- Jeff Gothelf, Product Management Author, Speaker, Trainer, and Coach

‍

2. The Evolution of Agile Roles

Key Highlights:

• More emphasis on technical leadership within teams rather than process-focused roles
• Shift from dedicated Scrum Master positions to embedded agile leadership
• Product management roles evolving to incorporate stronger business analysis capabilities

The job market for Agile roles is undergoing a significant transformation. Pure Scrum Master positions are evolving into hybrid roles that combine technical expertise with process leadership. This isn't just semantics - it reflects a deeper understanding that effective agile leadership requires both technical context and facilitation skills.

Engineering managers are expected to understand both system architecture and team dynamics. Instead of relying on external agile coaches, they're building these capabilities within their technical leadership. The focus has shifted from process adherence to technical mentorship and delivery optimization.

Product managers are also adapting to this new reality. They're becoming what some call "super ICs" - professionals who blend product thinking with solid business analysis skills. It's no longer enough to just manage a backlog; today's product leaders need to speak the language of both business and technology.

Expert take:

“First of all, I think it needs to be said, we should not panic. You do not need to abandon your career as a Scrum Master, Agile Coach, or Agilist of any kind. But we do need to think about it differently. Some suggest broadening your skills, which can certainly make you more valuable. Become a ‘technologist who is a Scrum Master’ or a ‘manager with agile coaching skills’. 

Keep in mind, this also may not require you to actually learn new skills, but to be smarter about how you position yourself and your existing capabilities. Know that organizations are looking for agile to be ‘baked in’ to the people they hire. You should broaden the scope of the types of roles you are searching for as well, because you might be surprised. I like to find companies that mention agile skills on job boards, then go and scour all of their open postings to see where else I might be able to apply.” 

- Brian Link, Business Agility Coach, Author, and Speaker 

‍

3. Cross-Functional Teams Become Truly Cross-Functional

Key Highlights:

• Teams capable of handling end-to-end delivery from discovery to implementation
• Breaking down traditional specializations in favor of full-stack capabilities
• Reducing dependencies between teams through better cross-functional team structure

The definition of "cross-functional" has evolved significantly. Modern engineering teams aren't just mixing developers and testers - they're creating truly autonomous units capable of handling the entire software lifecycle.

In effect, forward-thinking organizations are breaking down the remaining silos between frontend, backend, and DevOps specialists in favor of truly full-stack capabilities. Teams are increasingly taking ownership of the entire delivery pipeline, from initial discovery through to production deployment.

The most exciting part? Teams that embrace this approach are discovering they can deliver features faster and with better quality than ever before. When you own the entire process, you naturally make better decisions at every step. Plus, this approach not only avoids handovers and dependencies but also helps those teams develop into Product teams over time - armed with both domain knowledge as well as technical expertise.

Expert take:

“The nature of work is evolving. As challenges grow more complex and the pace of innovation accelerates, cross-functional collaboration is no longer a luxury — it’s a necessity. By embracing fluid roles, shared ownership, and open input, teams can unlock their full potential and deliver solutions that stand out in an increasingly competitive landscape.

So, the next time you hear someone talk about cross-functional collaboration, challenge them to think beyond meetings and updates. True collaboration means breaking down walls, embracing diverse contributions, and working together in ways that transcend traditional boundaries. Only then can we tap into the collective intelligence of our teams and achieve greatness together.” 

- Shubham Sharma, Senior Software Quality Engineer, Qantas

‍

4. Lean Takes Center Stage

Key Highlights:

• Growing adoption of "NoEstimates" and forecasting approaches over traditional estimation
• Emphasis on smaller, more frequent releases with clear business context
• Increased focus on flow efficiency and waste reduction in processes

The shift toward leaner practices is revolutionizing how teams approach delivery. Organizations are moving beyond story points and velocity metrics to focus on flow efficiency and cycle time. The "NoEstimates" movement isn't about abandoning predictability - it's about finding more reliable ways to forecast and deliver value with less overhead.

This shift toward leaner practices is complemented by a focus on smaller, frequent releases that tie directly to business outcomes.

Organizations are getting better at lean principles to identify and eliminate unnecessary steps in their processes, with a singular focus on value delivery. 

Expert take:

“Asking whether Lean is still relevant in 2025 is akin to questioning the relevance of continuous improvement itself. The answer is, of course, a resounding "YES!" However, the challenge lies not in Lean’s principles but in how effectively organizations implement and sustain their improvement efforts.

While many organizations adopt Lean methodologies, a significant gap remains between intention and execution. Common pitfalls include inadequate leadership commitment, failure to integrate Lean with organizational strategy, and lack of workforce engagement. Lean’s relevance hinges on addressing these challenges head-on by embedding continuous improvement into the DNA of an organization.”

- Patrick Adams, CEO and Executive Lean Coach, Lean Solutions

‍

5. Quality and Technical Excellence Make A Resurgence

Key Highlights:

• Renewed emphasis on XP practices and technical craftsmanship
• Greater focus on sustainable testing strategies combining automated and human testing
• Continuous refactoring and technical excellence becoming primary concerns

Technical excellence is back in focus. While the past decade saw many organizations chase velocity at the expense of quality, engineering teams are rediscovering that there's no sustainable agility without solid technical practices.

Extreme Programming (XP) practices, once considered too rigorous for many organizations, are seeing renewed adoption. And modern tooling has made these practices more accessible, but they still require disciplined engineering culture to implement effectively.

Testing strategies are evolving too, blending automated and manual strategies to ensure robust and adaptive systems. Advancements in testing technology—including AI-assisted tools—are enabling faster and more accurate testing processes, so quality remains a priority even in accelerated delivery cycles. 

Continuous refactoring has become a primary concern, especially as organizations deal with the technical debt accumulated during rapid pandemic-era digital transformations. Teams are finding that regular system evolution isn't just about clean code - it's about maintaining the ability to respond quickly to business needs without sacrificing stability.

Expert take:

“For me, XP is at the core of Continuous Delivery, which is also the foundation on which DevOps is built.

I don't think that you can achieve Continuous Delivery without the kind of polyglot collaboration between all of the parties involved in creating software. How can you Continuously Deliver if the Ops team, security team, testing team, dev team, or product team is in a silo? You can't.

I think that both of those approaches represent a genuine paradigm shift - it's a complete change in focus, not only about how to practice software development but really what software development is. I think of it much more in terms of it being this exploratory process of discovery and part of the way in which we organize our work is to enable that - to allow ourselves the freedom to discover things, learn new things, change direction, and discard the bad things.” 

- Dave Farley, Independent Software Developer and Consultant, Founder and Director of Continuous Delivery Ltd.

‍

6. Business Agility Extends Beyond IT

Key Highlights:

• Expansion of Agile principles beyond software development into broader business operations
• Integration of product-oriented thinking across organizations
• Focus on measurable business outcomes and value metrics

The walls between IT and business are finally crumbling. While software teams have been practicing Agile for years, we're now seeing these principles take root across entire organizations. A significant milestone in this evolution is the recent acquisition of Agile Alliance by Product Management Institute - a clear signal of the broadening demand for agile skills and expertise across different business functions.

Teams are adopting product-oriented thinking throughout the organization and focusing on measurable business outcomes rather than just project deliverables.

The data backs this up: while IT teams lead with 70% Agile adoption, product and R&D teams aren't far behind. Even traditional business operations and marketing teams are embracing agile practices, with adoption rates of 28% and 20% respectively. This shift is driven by necessity - in a world where market conditions change rapidly, no department can afford to operate in quarterly planning cycles anymore.

Consider Unilever's experience: By applying agile practices beyond their tech departments into marketing and product development teams, they've reduced time-to-market for new products by nearly 30%. This agility has enabled them to respond more effectively to changing consumer demands, particularly during times of economic uncertainty.

Expert take:

“Agile innovation has revolutionized the software industry, which has arguably undergone more rapid and profound change than any other area of business over the past 30 years. Now it is poised to transform nearly every other function in every industry. At this point, the greatest impediment is not the need for better methodologies, empirical evidence of significant benefits, or proof that agile can work outside IT. It is the behavior of executives. Those who learn to lead agile’s extension into a broader range of business activities will accelerate profitable growth.” 

- Darrell Rigby, Jeff Sutherland, Hirotaka Takeuchi for Harvard Business Review. 

‍

7. Agile Adapts to Remote and Hybrid Work

Key Highlights:

• Evolution of Agile practices to better support distributed and hybrid teams
• Development of new collaboration patterns for remote work
• Focus on asynchronous communication and documentation

Remote work has forced a fundamental rethinking of agile practices. The tools have evolved - Jira, Trello, and Slack are table stakes now - but the real innovation is happening in how teams structure their work and communication patterns to maintain the same level of engagement, communication, and velocity as in-person teams.

Distributed teams are developing new approaches to traditional ceremonies. Asynchronous standup updates combined with focused synchronous discussion time. Sprint planning split into async preparation and live refinement sessions. Retrospectives that blend individual reflection time with group synthesis.

Documentation, once seen as anti-agile, has found its place in the remote world. But it's not your grandfather's documentation - teams are using tools like Notion and Confluence to create living documents that evolve with their products. Architecture decision records (ADRs) and technical RFCs have become crucial tools for maintaining alignment across distributed teams.

Expert take:

“At one point, in-person face-to-face communication was the most effective way to communicate. This was still very true back in 2001 when Agile was defined, and this is why it was essential to document that in the Agile principles. However, the state of technology back then lacked the conductivity or capabilities to make remote possible, leaving workers desk-bound. The hardwired phone, desktop system, and limited email were what we had. So Agile worked to collocate teams and promoted in-person face-to-face meetings whenever possible in its first decade of existence. But that was 20 years ago.

For Agile, with today’s technology, we are not going against the intent of how we framed effective communications. On the contrary, the technology has helped remove the impediment that most large multinational and distributed teams were dealing with when adopting Agile — we can now have everybody face-to-face regardless of where they are in the world. Furthermore, Agile helps to give the hybrid workplace a set of values and principles to help the hybrid work environment prosper.”

• Ray Arell, Founder and Executive Director, nuAgility

‍

8. Economic Influences Shape Practice

Key Highlights:

• Greater emphasis on cost-effectiveness and demonstrable ROI
• Focus on π-shaped people and efficient team structures
• Renewed attention to productivity and outcome-based metrics

Economic realities are pushing organizations to rethink their agile implementations. The focus has shifted from process purity to practical outcomes. Teams are being asked not just to deliver features, but to demonstrate their impact on business metrics - aka cost-effectiveness and return on investment.

Value stream mapping has moved from theory to practice, as organizations work to understand and optimize their delivery pipelines. The most effective teams are those that can connect their technical metrics (lead time, deployment frequency, MTTR) to business outcomes (revenue impact, customer satisfaction, market share).

The investment in T-shaped individuals - those who combine deep expertise with broad capabilities - is proving particularly valuable in this environment. These team members can adapt to changing needs and help reduce the coordination overhead that often plagues specialized teams.

Expert take:

"Looking ahead, I anticipate a renewed emphasis on certainty, optimization, and individual performance metrics. This shift seems likely because developing self-management is challenging—it's a slow process for many and often tempting to fall back into familiar command-and-control habits. Unfortunately, such a trend risks diverting focus from user-centric goals and outcome-based measures, potentially undermining the core principles that have made Agile so impactful. To address this, I believe the Agile community must strengthen its foundation, focusing on creating working products and by leveraging tools like Evidence-Based Management to help measure the right metrics and progress indicators that some organizations require."

- Simon Bourk, Professional Scrum Trainer, Master Integral Coach TM

‍

Looking Ahead

As we move into 2025, we're seeing the emergence of a more mature, nuanced approach to agility. Organizations are moving beyond the framework debates and certification chases to focus on what truly matters: building high-quality software that delivers business value efficiently.

The most successful teams will be those that can:

• Maintain technical excellence while adapting to changing business needs
• Balance autonomy with accountability through clear outcome metrics
• Leverage automation and AI without losing sight of craftsmanship
• Scale agile practices through organization-wide adoption
• Adapt their practices to support distributed, async-first work patterns

The future of Agile isn't about choosing between SAFe and Scrum, or debating the merits of estimation. It's about building engineering organizations that can consistently deliver value while maintaining the technical excellence needed for long-term sustainability. The teams that get this right won't just survive the next wave of change - they'll lead it.

Exciting times indeed.