No items found.

Our Blog

Stories by Easy Agile

The latest industry news, interviews, technologies, and resources.

The Ultimate Guide to PI Planning

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 to help you run successful planning sessions, and build your confidence for your next scaled planning event.

We'll cover:

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.

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 should be included in the PI Planning agenda?

Here’s a standard PI Planning agenda template:

Day 1 AgendaDay 2 Agenda8:00 - 9:00 | Business Context8:00 - 9:00 | Planning Adjustments9:00 - 10:30 | Product/Solution Vision9:00 - 11:00 | Team Breakouts10:30 - 11:30 | Architecture Vision and Development Practices11:00 - 13:00 | Final Plan Review and Lunch11:30 - 13:00 | Planning Context and Lunch13:00 - 14:00 | ART Risks13:00 - 16:00 | Team Breakouts14:00 - 14:15 | Confidence Vote16:00 - 17:00 | Draft Plan Review14:15 - ??  |Plan Rework?17:00 - 18:00 | Management Review and Problem Solving?? | Planning Retrospective and Moving Forward

Source: scaledagileframework.com/pi-planning

This agenda might be perfect for you, or you might make changes based on the needs of your teams.

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.

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

In the next section, we'll help to define a few key terms that have been touched on.

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."

Definition:

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

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.

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?

There are 5 key roles in a PI Planning event:

  1. Release Train Engineers
  2. Product Managers
  3. Product Owners
  4. Scrum Masters
  5. Developers

Here are the responsibilities for each of these roles during PI Planning:

Release Train Engineer

The Release Train Engineer is a servant leader and coach for the ART. Their role focuses mainly on planning and facilitating the PI Planning event. This means 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 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.

Developer

Developers are responsible for researching, designing, implementing, testing, maintaining, and managing software systems.

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.

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

How to prepare for PI Planning

If you want to succeed at PI Planning, you need to prepare.

Every PI Planning event relies on good preparation so that your organization and attendees get the most out of the event and achieve your planning objectives.

The first step is to ensure that everyone involved properly understands the planning process. All people participating in PI Planning (along with key stakeholders and Business Owners) must be clear on their role and aligned on strategy.

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

To ensure that the PI Planning event runs smoothly, 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).

What happens after PI Planning?

After PI Planning, teams do a planning retrospective to discuss:

  • What went well
  • What went not-so-well
  • What could be better for next time
  • 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
  • Making sure that everyone has their belongings and leaves the event rooms clean when they go

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.

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.

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 📫

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
  • Agile Best Practice

    Agile Ceremonies: Your Ultimate Guide To the Four Stages

    This guide looks at the four ceremonies that bring one of Agile’s most popular frameworks, Scrum, to life.

    Learn how each agile ritual helps empower teams and drive performance while highlighting some tips to help your organization get the most from your ceremonies.

    At a glance:

    • The four agile ceremonies are Sprint Planning, Daily Stand-Up, Sprint Review and Sprint Retrospective
    • Ceremonies in agile facilitate visibility, transparency, and collaboration.
    • Each ceremony has a clear structure and objective.
    • Clear communication, flexibility, and cultural alignment are the keys to successful ceremonies.

    What are the main agile ceremonies?

    Agile ceremonies refer to the four events that occur during a Scrum sprint. Other forms of agile development, such as Kanban and Lean, also have similar practices.

    The agile ceremonies list includes:

    1. Sprint Planning
    2. Daily Stand-Up
    3. Sprint Review
    4. Sprint Retrospective

    While each ceremony is different, they facilitate the same overall purpose. The ceremonies bring teams together with a common goal under a regular rhythm, and they help teams get things done.

    "With today's enterprises under increased pressure to respond quickly to the needs of their customers and stakeholders, they must bring new products to market faster and accelerate improvements to existing solutions and services." - State of Agile Report

    Why are agile ceremonies important?

    Agile ceremonies help organizations adapt to change and succeed. With work planned in smaller portions and over shorter timeframes, they help teams quickly shift direction and course-correct when needed. They form a key part of the broader agile approach that’s now widely adopted in organizations worldwide.

    With agile ceremonies, teams in your organization can benefit from:

    • Enhanced ability to manage changing priorities
    • Acceleration of software development
    • Increase in team productivity
    • Improved business and IT alignment

    It’s important to remember that while ceremonies are an essential part of Scrum, they’re just one of many rituals that help create agile teams and workplaces. To realize the true benefits of agile, you’ll need to do more than include one or more of the ceremonies into your waterfall project.

    1. Sprint Planning

    The Sprint Planning ceremony sets teams up for success by ensuring everyone understands the sprint goals and how to achieve them.

    StructureAttendeesTimingDurationAgile FrameworkThe Product Owner brings the product backlog to discuss with the Development Team. The Scrum Master facilitates. Together, the Scrum Team does effort or story point estimations. The product backlog must contain all the details necessary for estimation. The Product Owner should be able to clarify any doubts regarding the product backlog. The entire Scrum Team (the Development Team, Scrum Master, and Product Owner)At the beginning of each sprintOne to two hours per week of iteration. So, if you're planning a two-week sprint, your Sprint Planning should last two to four hours. Scrum. Although Kanban teams also plan, they do it less formally and per milestone, not iteration.

    Outcomes

    After some team negotiation and discussion, you should have a clear decision on the work that the Development Team can complete during the sprint by the end of Sprint Planning. This is known as the sprint goal.

    The sprint goal is an increment of complete work, and everyone should feel confident about the commitment.

    The product backlog defines priorities that affect the order of work. Then, the Scrum Master transforms that decision into the sprint backlog.

    Top tips

    • Focus on collaboration rather than competition.
    • Break user stories into tasks to get things more operational for the Development Team. If there's time, assign those tasks during the event.
    • Factor in public holidays and any team member’s time off or vacations.
    • Keep your team’s pace in mind – a track record of the time it took to implement similar user stories would be helpful.
    • Focus on the product backlog and nothing else in terms of work for the sprint.

    2. Daily Stand-Up

    The daily stand-up brings the team together and sets everyone up for the day. The team uses this time to identify blockers and share plans for the day.

    StructureAttendeesTimingDurationAgile frameworkThis is an informal, standing meeting. All members of the Development Team inform everyone about what they did the day before and what they’re doing today. Members discuss any blockages they have and ask for help from the team if required. Due to time restrictions, the updates should be brief.Development Team, Scrum Master, Product Owner (optional) Daily, usually in the morningShort and sharp. No longer than 15 minutesScrum and Kanban

    Outcomes

    The Scrum Master should clear all the blockages that slow down or prevent the Development Team from delivering. As a result, the development process might need to change.

    This daily pulse check keeps the team in sync and helps build trust. Together, the group finds ways to support and help each other.

    Top tips

    • Use a timer to keep this meeting to 15 minutes.
    • Hold your stand-up at the same time every day.
    • Only discuss the work for the day ahead.
    • If the team is distributed, use video conferencing with cameras on.
    • Long discussions should happen after the event.
    • As the stand-up encourages progress, everyone should provide an update, and everyone should feel accountable.

    3. Sprint Review

    The Sprint Review is the time to showcase the team’s completed work and gather feedback from stakeholders. A variety of attendees from outside the team offer valuable insights from different viewpoints. This event also helps build trust with both external and internal stakeholders.

    StructureAttendeesTimingDurationAgile frameworkThe Scrum Master takes on the logistics of event preparation. The Product Owner should ask stakeholders questions to gather as much feedback as possible. They should also answer any of their stakeholder’s questions.Development Team, Scrum Master, Product Owner. Optionally, management, customers, developers, and other stakeholders At the end of the sprintOne hour per week of the sprint. In a one-week sprint, the Sprint Review lasts one hour.Scrum and Kanban. Kanban teams do these reviews after the team milestones, not sprints.

    Outcomes

    After this ceremony, the Product Owner might need to adjust or add to the product backlog. They might also release product functionality if it's already complete.

    Top tips

    • Schedule in time to rehearse before the meeting to help your team present with confidence, especially if external stakeholders are coming along.
    • Don’t showcase incomplete work. Review your Sprint Planning and the original criteria if you’re not sure whether the work is complete.
    • Besides product functionality, focus on user experience, customer value, and the delivered business value.
    • Consider ways you can introduce a celebratory feel to acknowledge the team’s effort.

    4. Sprint Retrospective

    In this final scrum ceremony in the sequence, you look back on the work you’ve just done and identify ways to do things better next time. The Sprint Retrospective is a tool for risk mitigation in future sprints.

    StructureAttendeesTimingDurationAgile frameworkThe teams discuss what went well throughout the sprint and what went wrong. The Scrum Master should encourage the Development Team to speak up and share not only facts but also their feelings. The goal is to gather rapid feedback for continuous improvement in terms of process. It’s also an opportunity to emphasize good practices that the team adopted and should repeat.Development Team, Scrum Master, Product Owner (optional)At the end of the sprint45 minutes per sprint weekScrum and Kanban (occasionally)

    Outcomes

    After this session, the team should clearly understand the problems and the wins that happened throughout the iteration. Together, the group comes up with solutions and an action plan to prevent and identify process problems in the next sprint.

    Top tips

    • Focus on both facts and feelings
    • Gather information that helps you focus on continuous improvement – this might include tools and relationships
    • Be honest and encourage ideas that solve process-related problems
    • Even if everything went well, have this meeting – retrospectives provide ongoing guidance for the next sprint.

    "With the speed of change expected to continue, the need has never been greater for an operating model that keep up." - McKinsey

    Agile lessons to live by

    As a team of experienced agile practitioners, we’ve picked up some key learnings about what it takes to get the most out of your agile ceremonies and create the foundations of a truly agile organization.

    Here are our top tips to make your ceremonies a success:

    • Be deliberately present - During the ceremonies, remember to take moments to pause and remind yourself of why you’re there. Show others that you’re present by giving them full attention and using your body language. In a remote setting, angle your camera as though you’re sitting across from them, look into the lens regularly, and use a distraction-free background.
    • Practice active listening - Think about what the person is saying, who they are, and what they need from you. Are they looking for a soundboard, do they need your help or opinion, or are they looking for an emotional connection?
    • Understand motives - Understand the motivations of your teammates before speaking. Consider why they should care about what you’re saying by connecting your message with their own motivations. Provide context where possible to let them know why your message matters.
    • Be flexible - It's important to remember that there is not a one size fits all approach to agile ways of working. What works for one team may not work for another, so you need to experiment to find out what works then tailor processes to suit your team's needs.
    • Create cultural alignment - The best processes in the world won’t deliver what you need if you don’t have the culture to support their delivery. Agile ceremonies need to be supported by a culture where people are actively engaged, confident to raise issues, and value continuous improvement.

    Agile ceremonies lead to better results

    While it can take time for teams new to agile to adjust to agile ceremonies, they are worth the effort. By providing a clear structure and achievable outcomes, they help align everyone on the product, communication, and priorities.

    The result? Agile teams that provide better quality products faster – and deliver real business outcomes.

    Wherever your organization is on your agile journey, it’s worth keeping in mind that each team and each suite of products are different, so there’s no standard recipe for success. The good news is that by working within the continuous improvement mindset the agile framework promotes; you too can iterate and improve your agile ceremonies over time.

    Ready to get started?

    Easy Agile TeamRhythm supports your team's agile practices in Jira. Supporting your team from planning right through to retrospective, TeamRhythm helps you and your team work better together to deliver value to your customers.

    Features include:

    • Agile sprint and version planning tool - Planning is quick and easy when you create and estimate issues on the story map. View your work under initiatives and epics, and see swimlane stats at a glance, ensuring team capacity is filled but not overcommitted
    • Agile story mapping - Map the customer journey using initiatives, epics, and stories alongside your agile Jira boards. Quickly and easily add new or existing stories inside the story map. Drag and drop to prioritize by value to the customer.
    • Product backlog refinement - Escape your flat backlog and view your work on the story map matrix. Drag and drop issues to prioritize or schedule. Quickly update story summaries and story point estimates with inline editing for a better backlog.
    • Team retrospectives - Celebrate success, gain insights, and share learnings with team retrospective boards for scrum and kanban, encouraging collaboration and transparency, so you and your team are continuously improving.
  • Workflow

    Why You Should Use SAFe (and How to Find SAFe Training to Help)

    If you want to better understand the characteristics of SAFe agile teams, and what leads to the successes and failures. Register now for our upcoming webinar.

    Do's and Dont's of Agile Teams with Adaptavist

    Tuesday March 8 AEDT

    REGISTER NOW

    Large organizations use SAFe Agile to improve their operations. When you use this framework, you scale Agile to create a Lean enterprise.

    This approach helps meet the challenge of delivering constant value. It also helps to support continuous improvement.

    Another benefit of using SAFe® is that you get to plan and apply a predictable workflow schedule. When leaders link strategy with implementation, they increase their performance and productivity.

    SAFe stands for scaled agile framework enterprise. You can use this framework to apply agile methodologies, such as Scrum or Kanban, to larger teams. SAFe training and certification courses help leaders plan and implement the philosophy.

    In this article, you’ll learn about the benefits SAFe can offer your enterprise and how effective organizers lead and implement SAFe. You’ll also hear about training courses that can help.

    Want to empower your team to implement the Scaled Agile Framework (SAFe)?

    Try Easy Agile Programs for Jira

    Free Trial

    Major benefits of implementing SAFe

    SAFe values alignment, transparency, quality, and execution. It inspires enterprises to adopt lean-agile thinking across multiple departments or teams. Lean methodology means higher productivity, reduced costs, and improved work quality. By identifying value streams and streamlining work processes as you implement SAFe, you can start to create a Lean enterprise.

    💥 Achieve team alignment at scale: Easy Agile Programs product demo 💥

    Register

    By implementing SAFe, you gain the tools to support lean thinking. You create Scrum teams who understand what the user wants, how to deliver those changes with minimal time waste, and create efficient processes. SAFe will also clarify roles and processes so teams can quickly react to problems.

    Many large companies have applied SAFe and report major benefits. One of these benefits is increasing employee satisfaction and productivity by as much as 50%. Then, there’s up to a 75% increase in product quality and time to market.

    SAFe methodology teaches you to apply a systems approach to pain points, workflow management, and value streams. A healthy amount of cross-team collaboration can begin. The end goal is enhanced value flow.

    The transition to using SAFe can take time and trial and error. Being brave enough to engage on a meaningful level and produce better quality outcomes is part of this new norm.

    Beginning to use SAFe: The big picture

    Using SAFe in your organization can be a major transition. You’ll need to consider how effective leadership and implementation will help make this transition.

    1. Leading SAFe

    Leading SAFe means building cross-functional teams and developing workflows that help your team get the most value out of planning. That way, software development teams can quickly respond to customer’s needs.

    A solid SAFe leader improves productivity, product quality, and time-to-market.

    Other identifiers of quality SAFe leadership include better team member engagement, which helps work better and feel part of a supported and supportive team. The value that individuals bring to the organization then increases.

    Leading SAFe course

    The Leading SAFe® training course is foundational. You’ll mainly learn about SAFe principles and their practices.With SAFe certification, you learn how to apply and scale the scaled agile framework for Lean and agile development. You’ll also learn how to plan and implement Program Increments (PI).

    Once you have this information, you can guide transformation across your organization.

    2. Implementing SAFe

    To properly implement SAFe, you need to know how to coach agile teams through the SAFe framework and Lean-Agile mindset.

    Before you can do this, you need to know how to identify and maximize value streams in work processes. In doing so, you’ll increase team collaboration. By increasing collaboration, you’re better positioned to produce value for product owners.

    As you implement SAFe, you’ll constantly develop solutions to organizational problems and understand each person’s role in this framework.

    Essentially, you start and sustain long-term change that increases value and profits. You then coach others on how to capture the value and apply SAFe principles in practice to achieve long-lasting change.

    Implementing SAFe course

    Implementing SAFe® is another foundational course. This training course offers an in-depth look at the SAFe Agile framework. It also teaches you how to apply your learning.

    In this course, you’ll learn how to design a SAFe implementation plan, plan for enterprise transformation, introduce and launch Agile Release Trains (ARTs), and encourage the organization to be a lean enterprise. You’ll become a large-scale agile coach who teaches others to see and apply large solutions.

    Implementing SAFe is ideal for anyone who wants to know how to lead transformation. It focuses on leading SAFe with remote teams. You get to find out how to create Agile Release Trains (ARTs) and show others how to design ARTs.

    More SAFe roles and processes

    As you learn how to incorporate SAFe, you’ll need to focus on empowering key team members and focusing on some crucial areas. SAFe training is available for some of these roles and processes.

    • The SAFe Advanced Scrum Master coaches Scrum teams as they adopt the agile mindset.
    • Lean Portfolio Management helps with cross-team collaboration as you adapt to customer needs.
    • The SAFe Release Train Engineer is key for Agile Release Trains. This person works on PI Planning, among other events. This, along with the product manager, is a core position for leading SAFe to get the most out of value streams
    • A Certified SAFe Program Consultant (SPC) leads change across the enterprise at all levels by coaching and training team members as they adopt the lean-agile mindset. The SPC also organizes and mentors employees to encourage ongoing engagement.
    • You’ll need to empower teams to learn how to be a skilled member of an Agile Release Train.

    Are you a Release Train Engineer or Program Manager struggling to effectively manage an agile release train or program?

    Register for Easy Agile Programs Product Demo

    As a proud Scaled Agile Platform Partner, Easy Agile Programs enables Release Train Engineers and Program Managers to effectively manage programs at a ‘team-of-teams’ level to deliver alignment at scale.

    Try Now - Free Trial

    More Agilist certification courses include training as a release train engineer and a SAFe Scrum Master. You can also take these two-day to four-day certified SAFe training courses to improve your competencies.

    For advice on which certified SAFe courses are best for you, go through these FAQs to boost ongoing improvements in your organization.

    SAFe training for better enterprise agility

    Adopt SAFe to create a Lean enterprise with large-scale change. It encourages cross-team collaboration, systems thinking, and a lean mindset.

    While SAFe can take time to implement, there are resources to help, including SAFe training courses. Choose to focus on team members and processes that can most benefit from extra guidance.

    You can also follow the Easy Agile blog, podcast, and learning hub for extensive guidance on agile principles, roles, and tools.

    Streamline visibility and provide transparency of your Program

    Easy Agile Programs Product Demo

    Register Now

  • Workflow

    How to Make the Most of Your Sprint Goals

    The sprint goal is a key aspect of any sprint, and it should be front and center throughout your two-week process. The goal ensures the team is aligned on a clear purpose for the sprint, and, if done well, the goal inspires the team to stay on track throughout the entirety of the sprint.

    So, what makes a good sprint goal, and how does the sprint goal fit within the framework of a sprint? In this post, we’re going to race (or should we say sprint 😉 ) through a recap of the Scrum process, followed by a list of five critical elements of an effective sprint goal. You’ll learn how to best create, manage, and follow through on your sprint goals for a successful sprint every two weeks.

    An overview of the Scrum process

    We’re big fans of Scrum! Need a little refresher? Here’s how the Scrum process works and where the sprint goal fits into the whole picture.

    Scrum is an agile framework used primarily by software development teams that provides team members with a streamlined workflow to meet stakeholder and customer needs. The Scrum workflow has four meetings (also known as ceremonies), which all have a distinct purpose. This structure means team members can easily support each other by sharing, tracking, and enhancing deliverables.

    The Scrum framework divides work into repeating two-week sprints where a set amount of work — the sprint goal — is completed. Each Scrum begins with a sprint planning meeting, and during this time, the product owner defines the sprint goal. They choose which tasks will move from the product backlog to the sprint backlog to be completed over the following two-week sprint.

    Product backlog items represent the whole picture of what needs to be accomplished before completing or releasing a product. Sprint backlog items are what the team will (hopefully) accomplish over the course of the sprint.

    The Scrum Master acts as a Scrum guide who leads the team through the meetings and steps of the Scrum process. Throughout the sprint, the Scrum team meets for a daily Scrum to check in with one another and report on what work was completed over the previous 24 hours.

    At the end of the sprint, a sprint review and sprint retrospective help the team gather feedback from stakeholders and improve upon their processes before the next sprint begins. The entire process repeats again with sprint planning and continues to repeat until the product or project is complete.

    Easy Sprint Planning:

    Drag items directly from your backlog onto your TeamRhythm User Story Map. Inline edit story summaries and story point estimates. Display your sprint goal on each sprint swimlane.

    TRY: TEAMRHYTHM SANDBOX DEMO

    What makes a good sprint goal?

    The sprint goal keeps the team focused and aligned on what everyone is trying to accomplish for each sprint. It’s an extension of the overall product or project goals, but the sprint goal can zero in on key components the team wants to tackle for that specific sprint.

    What makes a good sprint goal? Let’s find out.

    1. The goal is achievable

    The objective of the sprint needs to be achievable within the sprint’s allotted time frame. Generally, in a Scrum framework, the team is time-bound to two weeks.

    As new information is gained and other impediments occur, there’s always a chance the sprint goal won’t be met. But that shouldn’t stop you from setting achievable goals. When a team continually fails to meet the goals of the sprint and the project, morale and enthusiasm will decline.

    It’s crucial that sprint goals are manageable within the allotted time of the sprint. Sprint goals can become too large when a team tries to accomplish too many different components at once or if too much of the product backlog makes it into the sprint backlog. Rather, take a reasonably achievable workload out of the product backlog to form the sprint backlog. Otherwise, you’ll end up with one daunting overall list and no clear direction for each sprint.

    2. The team understands the definition of done

    The clearer the sprint goal, the better. You need to clearly define the goals of the sprint and what it means to be done. How will the team know if they achieved the desired outcomes? What does “done” look like? Does everyone agree on this definition for every given task and the overall goals of the sprint?

    Your goals need to be measurable to limit ambiguity, subjectivity, or conflicting opinions around the success of the sprint.

    When a team is aligned, and everyone understands what needs to be accomplished, decision-making improves, and each aspect of the Scrum team can work harmoniously toward the same aims.

    3. The sprint goal is meaningful to the team

    Beyond knowing what the team hopes to accomplish over the course of each sprint, the team needs to understand the reasoning behind the sprint goal.

    Make sure everyone understands why they are working towards a specific sprint goal. What meaning does the sprint goal have? Ideally, the meaning of the sprint goal will relate back to stakeholder needs, the customer journey, or the user experience of your product.

    Visualize and prioritize the work that will deliver the most value to your customers

    Easy Agile TeamRhythm

    TRY NOW

    4. The sprint goal aligns with the overall product goals

    The sprint goal can zero in on a specific aspect of product development, but it should still connect to the overall product goals.

    While creating sprint goals, ensure the overarching product vision isn’t lost or ignored. Every sprint, while specific to its own set of goals, should work toward accomplishing your product goals.

    5. The sprint goal is visible throughout the sprint

    The sprint goal can’t be a “set it and forget it” aspect of your sprint. It should be visible to the team the entire time, and the team needs to continually check in on the goal to ensure they’re on track to achieve it.

    The shared goal should be front and center of daily Scrum meetings. If possible, display the sprint goal for everyone to see. As you accomplish backlog items and work through the sprint, continually reference the sprint goal and the progress you are making toward it. How likely are you to achieve the sprint goal considering the time you have remaining in the sprint? What might be standing in the way of achieving this goal?

    During the sprint retrospective, you should discuss the success or lack of success the team made on the sprint goal. What went well and contributed to your success? What didn’t go so well that you could change or do differently for the next sprint?

    With Easy Agile TeamRhythm, each scrum board in Jira will have an associated User Story Map.

    Throughout the sprint, the team can refer to the User Story Map to make sure they’re on schedule, coordinate dependencies, and keep sight of the big picture.

    TAKE A PRODUCT TOUR

    A customer-centric approach

    Let’s recap a few of the most important factors to remember when establishing and following through on your sprint goal:

    ✅ Ensure the goal is achievable.

    ✅ Ensure the team understands the definition of done.

    ✅ Ensure the sprint goal is meaningful for the team.

    ✅ Ensure the sprint goal aligns with the overall product goals.

    ✅ Ensure the sprint goal is visible throughout the sprint.

    Thanks for sticking with us and utilizing the Easy Agile blog. We’re passionate about helping teams work better with agile. We have a suite of Jira apps designed to keep the customer top-of-mind through every step of the development process.

    Looking for a tool to streamline your sprint planning sessions? Check out Easy Agile TeamRhythm, which transforms the flat product backlog into a meaningful picture of work.

  • Workflow

    DevOps vs. Agile: Differences and Common Ground

    DevOps vs. agile—what’s the difference? These two methodologies have a lot in common, but there are also many key differences that we’ll discuss in this post. You might say they compliment each other. We wouldn't go so as far as to say they’re like peanut butter and jelly, but when used together, they certainly make for a nice combination.

    In basic terms, it comes down to this: Agile solves the gap that can exist between end users and developers, whereas DevOps solves the gap that can exist between developers and operations.

    Sound simple enough? Well, there’s a lot more to it than that. Let’s dig a little deeper into the definition of both agile and DevOps, what these methodologies have in common, what makes them different, and how they can work together.

    Defining agile

    The agile methodology was first popularized in software development, but in recent years, agile practices as well as the guiding principles of agile have expanded into a range of different industries that want to prioritize continuous improvement and growth.

    The agile approach to project management is much different than the traditional approach to project management. Traditional project management follows a waterfall model. Each project element must be completed before moving on to the next in a strict sequential order, and the flow of work remains the same from project to project.

    Agile focuses on flexibility, adaptability, collaboration between team members, and delivering consistent value to stakeholders through continuous customer feedback and rapid releases. Each iteration offers fresh insights into what is and isn’t working and what could be improved upon. It’s a multidimensional approach that eliminates the bottlenecks so characteristic of traditional project management.

    Agile teams can implement agile in a variety of different ways, including Scrum, kanban, lean, and more. A key benefit of agile software development is the ability to bridge the gap between customers or users and development teams.

    Learn more about agile, dig into the Agile Manifesto, and read our article: Agile 101: A Beginner's Guide to Agile Methodology.

    Defining DevOps

    DevOps is a software development method that empowers teams to build, test, and release software quickly and consistently with the integration of agile practices and principles, including enhanced automation and improved communication and collaboration between development and operations teams.

    DevOps focuses on aligning development and IT operations to better manage end-to-end engineering processes. In the past, development teams would write applications and then pass them along to an operations team that would then deploy and manage the software. The problem with this approach is the operations team is given no insight into how the application was developed.

    DevOps practices bridge the gap between developers who develop and write the software and operations who run the software.

    ➡️ Learn more about other popular software development methodologies.

    DevOps vs. agile: What do they have in common?

    Both agile and DevOps aim to aid the software development process, but where did they come from, and what commonalities do they share?

    In this “which came first, the chicken or egg?” scenario, we do actually know which came first. 🐓🥚 Agile, which gained popularity in the early 2000s, provided development teams with an approach to solving complex problems. While agile solved many problems, there was one disconnect that remained — the operations teams deploying the software were sidelined and remained in a silo, missing out on the benefits of agile.

    Enter DevOps, which applies agile principles to improve the gap that often exists between development and operations teams. It offers operations teams visibility into the development process so that they can better understand how and why a product was made. This clarity aids the development process since both sets of teams can work alongside one another while developing and deploying.

    The result is development practices that run smoothly from one team to the next, a heightened consideration of the user, and continuous delivery to both customers and stakeholders.

    So, in many ways, DevOps is an extension of the original agile methodology. DevOps teams  zero in on a key aspect of the development process to bring development and operations together. Many of the same agile principles are applied, such as continuous deployment, improved collaboration, iteration, and automation, and implementing feedback at every turn.

    Key differences between DevOps vs. agile

    While agile and DevOps have a lot in common, there are a few key differences to be aware of. The differences mainly stem from the different types of teams utilizing agile principles. These different teams have different needs, work at a different pace, and are guided by separate feedback systems.

    AgileDevOpsAgile is a broad methodology that focuses on solving complex problems and bridging the gap between development teams and product/project management through improved communication and collaboration, continuous iterative development, stakeholder feedback, and frequent releases. DevOps takes agile one step further, focusing on bridging the gap between development and operations teams to better manage end-to-end engineering processes. Agile can be applied to any industry that wants to emphasize continuous improvement, collaboration, and communication. DevOps is mostly used within software development.There are many different frameworks that can be utilized to implement agile, including Scrum, kanban, lean, and XP (eXtreme Programming).DevOps is an agile framework that exists because of agile.Agile focuses on iterative development and working in small batches.DevOps emphasizes constant testing and delivery automation. Agile development is typically managed through sprints: 2-4 weeks time in which a set amount of work is completed and submitted to stakeholders for feedback.The goal of DevOps is to deliver code to production as frequently as possible, either every day or every few hours. Feedback comes from stakeholders, customers, and users.Feedback comes from the internal team. Agile uses the Shift Left testing approach (testing early and often to get the code right the first time, reducing the time it takes to get the product to market).DevOps uses both Shift Left and Shift Right testing to get the code right the first time and to understand and optimize the software’s functionality and usability in real-world situations, enabling wider test coverage.

    Bridging every gap in the development process

    Let’s bring it all back to the simple definition we began with. Although there are many complexities, similarities, and differences between DevOps vs. agile, in basic terms, it comes down to this:

    Agile, which came before DevOps, is a broad methodology that primarily focuses on bridging the gap between the customer/user and development teams. DevOps, which came second, utilizes agile practices to fill the void that remains between development teams and operations teams.

    Easy Agile is dedicated to helping all types of teams work better using various agile methodologies. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams work better together, and deliver for your customers.

    Book a 1:1 demo

  • Agile Best Practice

    5 Ways Every Development Manager Can Boost Team Performance

    When you take on the development manager role, it can feel like you're doing a little bit of everything. Your job is no longer to focus purely on code — and you're not leading your average team. In your day-to-day, you're representing, strategizing for, and even developing with your engineering team.

    With all the tasks filling your to-do list, it can be easy to forget: Getting quality results depends on the quality of your leadership. Work isn't just about projects — and you're not a project manager. Great development managers are equally as good at working with people, building culture, and supporting their team members as they are at boosting efficiency and working on all things technical.

    To get the most out of your team, here are five tips that every development manager needs to know to get the best from their team.

    1. Offer guidance, not micromanagement

    Have you ever gotten anything done with someone breathing down your neck? It's not comfortable, and it creates a culture of distrust. In an agile environment, this goes against the principle of having a self-organizing team — one in which each team member takes charge of their own responsibilities and timelines.

    A great development manager knows that each team member contributes their own unique work experience and knowledge to a team. Your job description isn't to do other people's jobs for them or boss them around. Rather, it's to ensure the engineering team produces quality products in a timely manner.

    You'll get more out of your team by inspiring them instead of telling them what to do. Instead of dictating deadlines, guide your team in the right direction by illustrating the importance of your priority projects.

    How will each person's contribution impact the broader company? How will finishing one task early unlock new opportunities for the team? Nudge your employees toward better decisions that they make themselves to build a team that's enthusiastic about their work.

    2. Plan with the big picture in mind

    Development manager: Glow Up Make-Up GIF

    While members of your product development team may be diving into the details — writing code, checking off smaller tasks — your job as a development manager is to think big. Development managers play a key role in the agile planning process by figuring out which projects their team should prioritize and how to best complete them.

    Instead of just thinking solely about what's best for your team, you need to consider which projects and tasks best align with your company's broader business goals. This will help you build a development team that creates stand-out results for the entire company.

    At the same time, you should be fully aware of what's possible for your team to take on. Will committing to one new product up one person's workload far more than others? Does your team have the capacity for more work at all? No matter how many years of experience your team has, they — as individuals and as a whole — need room to breathe so they don't burn out.

    3. Keep your technical skills up-to-date

    "Manager" may be the brag-worthy highlight of your job title, but that doesn't mean you can let your technical skills go. Odds are, coding will still make up a chunk of your day-to-day — or at least your week-to-week. Even when you're not directly assigned to a software development task, you'll still need to guide your team members through their individual tasks.

    To give your team the support they need, you need to be able to speak their coding language. This will help you lead code reviews, take part in technical conversations, anticipate (and prevent) roadblocks, and ensure you're implementing the most efficient technologies. Regularly taking courses and joining a coding community are two simple ways to be a problem-solving champion for your engineering team.

    Your technical expertise will help your team stick to your product roadmaps and meet key milestones.

    4. Bolster your communication skills

    Development manager: MasterChef Junior Communicate GIF

    When you take on the development manager job, you become a liaison between your engineering team and other parts of your organization. For example, you might communicate the needs of your developers to senior management or pass on requests from sales managers to your team.

    People without a technical background might think you're talking about music if you start talking about C#. Engineers without business management experience may roll their eyes if you start talking about five-year plans instead of an upcoming product launch. Even though coworkers share the same company culture, they don't necessarily "get" each other all the time.

    Developer managers are translators who represent their team and deliver messages back to them as needed.

    Since you're constantly working with people from different backgrounds, you need to strengthen your interpersonal skills. Get to know how you can best communicate with different people. Which teams prefer email over texting? Who's the go-to contact person for each team? Does anyone listen better when they're not hungry? 🙋

    The stronger your communication skills are, the more likely your team will get the resources they need, and the better they'll connect their priorities to your company's.

    5. Be available to support your team members

    Development manager may be a part-time managerial and part-time technical role, but in this position, you need to be a full-time leader for your team. When you want to consistently improve your team's output, you need to put your top-notch leadership skills into practice day in and day out.

    As a development manager, you need to act as a coach of sorts for your team members. Schedule out recurring one-on-ones with your team members, during which you can chat about career goals and pain points on top of current projects. When you have a new hire, chat with them about their desired career path during the onboarding stage.

    Based on what you learn, you can brainstorm ways to support their professional development. You don't have to pay for their bachelor's degree to help them succeed. Connect them to mentors, send them to conferences, recommend them for speaking opportunities — your options are endless (and simpler than you may think).

    Offering support on both current projects and in long-term career goals is your chance to invest in your employees. It'll help them become better workers — and they'll feel valued, too. Did you know nearly half of employees leave their jobs to gain new skills? Keeping your development team at its best in the long run requires you to help each employee grow.

    Lead your team as an effective development manager

    Leading your development team to success takes an unbeatable blend of people skills, technical skills, and leadership skills. In your multi-faceted role, your ability to communicate and align your team with the rest of your organization is invaluable.

    With Easy Agile Roadmaps for Jira, you can make team alignment simpler by dragging and dropping any Jira issue on a visual timeline. Watch our demo today to see how this tool can help your engineering team shine!

  • Agile Best Practice

    Project Portfolio Management: 5 Steps Your Team Should Take

    Taking on new projects doesn't always help you achieve your business goals. When you want to grow in the direction of your goals without detours, you need to prioritize the projects that align with the path. Prioritizing begins with getting a holistic view of your business activities and objectives. Using project portfolio management (PPM), your team can focus on the big picture and align your goals with every move you make.

    Keep reading as we explain what PPM is, its benefits and the five-step process you can take to implement it.

    What is project portfolio management?

    Project portfolio management is the process of managing a group of related projects together with the goal of improving overall business performance. Instead of focusing on projects one at a time, this centralized management process considers how prioritizing specific projects affects your ability to meet broader business objectives.

    In a project management office (PMO), project portfolio managers are in charge of developing high-level strategies that help you make the most of all the resources you have. However, unlike individual project managers, project portfolio managers aren't involved with executing projects once they're selected.

    Three benefits of project portfolio management

    Much like stars in a constellation, individual projects and goals shine their brightest when you see how they're all connected. That's where the PPM process comes in handy. When you start practicing project portfolio management, you can experience these three benefits:

    1. Improve your decision-making

    PPM challenges your team to evaluate each project based on how well they align with your strategic goals. Instead of solely aiming to take on more projects — which can quickly lead to project overload — teams that use the PPM process focus on forecasting the benefits and risks of each opportunity. This way, you only commit to projects that suit your company's needs.

    Whereas taking on too many irrelevant projects can lead to lots of work with little return, using the PPM process to make better decisions can help you choose high-impact projects that propel your team toward its goals. 🚀

    2. Reduce your project failure rate

    A lack of centralized planning can leave a lot of room for project failure. Your resources might be spread too thinly, or inefficient workflows may riddle your projects. When your organization includes project portfolio managers who look at the big picture in addition to individual project teams that focus on the details, you can better spot potential agile planning mistakes before they occur. Risks like overspending and poor scheduling are less likely to be an issue if you're considering the broader organizational strategies, budgets, and timelines that tie all of your projects together.

    For your stakeholders, a lower project failure rate means more value is delivered over time. A software company, for instance, can reduce the gaps between new product or feature launches by ensuring they’re only working on projects they’ll complete.

    3. Increase your team productivity

    PPM allows you to see a broad overview of what your team members are working on across projects. As a result, you can better designate tasks based on which team members are best fit for each role and allocate resources based on your priorities. This optimization can help you improve your return on investment (ROI). Plus, optimizing helps avoid team member burn out by eliminating excess work.

    The 5-step project portfolio management process

    With project portfolio management tools projected to be a $3.2 billion market in 2021, it's clear that many agile teams are implementing PPM in their organizations. Regardless of what PPM tool you use, these five steps are key to successful centralized management.

    1. Identify your business strategy

    The first step in effective project portfolio management is identifying your company's strategic objectives. When you clarify what your organization wants to achieve — including key performance indicators (KPIs), which are metrics that measure success, and objectives and key results (OKRs) — your team can work toward a shared vision.

    Afterwards, establish a project prioritization process. Decide what steps you’ll take to determine how well a project aligns with your goals. For example, some businesses may use a scoring model, giving projects numerical scores in key categories until they find the highest averages. Others may simply weigh the costs and benefits of each project with overall business objectives in mind.

    2. Make lists of your current and potential projects

    To start optimizing your project portfolio, take inventory of your current projects, as well as projects you've been considering. Take note of your project statuses, categories, and other details that can help you gauge each project's relevance to your business goals. You can also estimate the resources you need to execute each project. This estimation can further help you measure costs and feasibility, so you can effectively perform resource management.

    ​3. Evaluate your project portfolio

    Once you finish compiling your list, you can begin using your project prioritization methodology to evaluate projects. As you determine if each project is beneficial for your business, don't forget to consider feasibility. If a project isn't feasible, then it's a no-go for your team. By the end of your evaluation, you should have a list of projects that align with your goals and provide the most value to your business.

    Ideally, your portfolio should include a mix of projects that help fulfill short-term and long-term objectives. This way, you can secure the returns you need to maintain your current growth rate while leaving room for innovation that leads to exponential growth in the future.

    4. Allocate available resources

    As soon as you narrow down the number of projects you want to take, start with resource allocation. Divide your budget, team members, and other resources between each of your priority projects. You'll also need to create a timeline for your project portfolio that includes each project's deadline. You can include key milestones to make your timelines more detailed, too.

    Risk management is another crucial aspect of this step. If you notice that you don't have enough resources to complete all the projects you’ve selected, reassess your priority projects until you build a portfolio that doesn't stretch your team too thinly. (And if you can't afford to give everyone a car like Oprah, don't. 🚗)

    5. Adjust your portfolio and resources as you go

    A critical component of project portfolio management is tracking your projects throughout their life cycles. Keep a close eye on your project performance, including your ROI, project failure rate, and other KPIs as you begin executing the projects you chose. If your project portfolio doesn't perform as desired, you can adjust your resource allocation in real-time, instead of addressing issues when it's too late.

    Tracking key metrics can also help you improve your PPM process as you go. For example, if your project prioritization methods aren't helping you reach your financial goals, brainstorm more effective ways to evaluate each of your projects.

    Zoom in on the details with Easy Agile Programs

    Project portfolio management is a useful process that can help your agile team make decisions with a bigger picture in mind. Instead of hyper-focusing on individual projects, the PPM process enables you to remove roadblocks from your broader workflows and maximize resources across an entire portfolio. This way, you can keep driving a straight path toward your business goals.

    Of course, the big picture isn't everything. To be a well-rounded agile team, you need to zoom in on the details every so often, too. With Easy Agile Programs, you can get more context on your projects, so you can continue maximizing your organizational growth.

  • Workflow

    How to Complete the Value Stream Mapping Process

    "Bottleneck" is a buzzword you don't want to hear. When it comes to your production process, maximizing your time and budget is all about keeping efficiency high. However, simply cutting the steps in your process may not make your customer any happier. If you want to achieve a high return on investment and increased customer satisfaction, value stream mapping is an ideal way to keep your team on track.

    What is value stream mapping?

    Value stream mapping (VSM) is a technique from the lean principles methodology that helps you visualize the steps you need to take to deliver a finished product or service. Value stream maps outline the flow of information and the physical materials to see where value is added for the customer. The purpose of VSM is to increase efficiency by reducing waste in the production process.

    Widely known as the lean manufacturing method used in the Toyota Production System, VSM is now often used to eliminate bottlenecks in other industries like software development, supply chain, and healthcare. It's a versatile technique that can help many organizations shine. 🌟

    Streamline visibility and provide transparency of your Program for all teams

    Easy Agile Programs

    Join a demo

    Why value stream mapping matters

    When companies aim for efficiency, they often focus on reducing the total amount of production steps required. But customers don't always see what happens behind the scenes. Decreasing the length of your workflows mainly benefits your process without changing the experience for them. On the flip side, the value stream mapping process keeps your team members aware of customer needs, so your business can stand out.

    For teams that use value stream mapping, reducing inefficiencies is all about cutting production process steps that don't add value. Value stream maps are a visualization of where you're wasting effort. They show your team that keeping steps within your process is okay — but each of those steps should help customers in some way. As a result, VSM prevents overproduction while ensuring your customers are happy with your final product or service.

    You can achieve better lean agile workflows with value stream mapping and effectively keep up with customer demand. 💪

    Value stream mapping terms

    A typical value stream map is divided into three key sections — information flow, material flow, and lead time ladder — that help you see where process improvements can occur. To help you complete each part of a value stream map with greater ease, we'll explain a handful of common terms that you'll come across in each section.

    As you learn these terms, you can refer to this Microsoft template to see a few VSM symbols that you'll often use.

    Information flow

    At the top of a standard value stream map is an information flow section that shows how data transmits between your team members, customers, and other stakeholders. Common terms you'll need to know to complete this section include:

    • Customer: This is the consumer who will receive your final product. Your customer is represented in the upper right corner of your map.
    • Supplier: This is your organization. Suppliers are placed in the upper left side of value stream maps.
    • Dedicated process flow: This is a process or department (like "production control") that information flows through.

    Material flow

    In the middle of a value stream map is a material flow section that shows how you take your product or service to delivery, step by step. Each box represents a unique task, which may be performed by the same team or by another after a material handoff.

    To complete the material flow section, you need to know these terms:

    • Shipments: On value stream maps, "shipment" arrows point from the supplier to the first step in the material flow, or from the last step to the customer. They show how your information flow is related to the start and end of your production process. For example, an arrow can show how raw materials move between the supplier and factory or how software access is "sent" to a user.
    • Cycle time (C/T): This metric represents the amount of time required between shipments.
    • Inventory: Inventory is what's produced between each stage of the production process. Your inventory is usually written below a triangle with a "I" within it. 🔺

    Lead time ladder

    At the bottom of a value stream map is usually a time ladder that helps you visualize your lead time, which is the average time spent on each step of your material flow.

    Kaizen burst

    Throughout your value stream map, you can include Kaizen bursts. These represent bursts of activity (like a sprint) in which your team focuses on resolving a specific issue — such as processing customer returns — to quickly remove potential bottlenecks. The symbols for Kaizen bursts look like comic book explosions to grab your attention. 💥

    How to create a value stream map

    When you're ready to get started with value stream mapping, select the specific product or service that you want to create a map for. While all production processes can benefit from continuous improvement, you should ideally start with a product or service that could benefit the most from VSM. Once you've made your selection, follow these steps with your VSM team:

    1. Define your objective: Identify what you want to change for the customer as a result of the value stream mapping process. For example, you might want to improve the quality of a product or the speed with which you deliver a service.
    2. Clarify your scope: Define the start and end of your value stream map. You can create a map that includes all of the steps between concept and delivery, begin with an inefficient part of your value stream, or end with a contract agreement instead of a traditional delivery.
    3. Outline your process: List each step of your production process. Begin by speaking with team members from each department involved in the process to gather any needed insights. Your list should include non-value producing steps. Collect data about cycle times, lead times, inventory, and more to understand each step even further.
    4. Create and evaluate your current state map: Using the information you’ve gathered, create a map that reflects the current state of your process. Work with your team to identify which steps are productive and where improvements are needed. This map will allow you to pinpoint areas of waste, like long process times or software downtime.
    5. Develop a future state value stream map: Create a second map that illustrates an improved process that eliminates non-valuable steps. This will be the map you'll ultimately follow to reach your objectives.
    6. Build an implementation plan: To start moving toward your future state, establish how your team will implement the new process. Include what metrics you'll keep an eye on to ensure you're on track to reach your objectives. You can also establish how frequently you'll review your progress and adjust your future state map (if needed) during the implementation phase.

    📣 Achieve team alignment at scale with Easy Agile Programs

    Join a demo

    Continue adding value for your customers

    Learning to see from your customer's perspective is crucial to ensuring you stand out from your competitors. Following the value stream mapping process can help you visualize where your team is producing value and where you're doing extra work that can easily be eliminated.

    To continue adding value for customers, learn how Easy Agile Programs can help you dive deeper into your product’s customer's journey.

    Try Easy Agile Programs for Jira

  • Workflow

    7 Lean Methodology Benefits for Development Teams

    The lean methodology is all about eliminating waste and improving efficiency to maximize and deliver consistent customer value. Under lean, if a process doesn’t bring value to the customer, it’s considered wasteful and is eliminated or reduced as much as possible. It’s a development method and guiding mindset that helps teams refine their processes in the name of efficiency, effectiveness, and continuous improvement.

    Here, you’ll learn about the origins of lean as well as 7 key benefits of adopting the lean methodology.

    An intro to lean methodology

    The lean methodology grew out of lean manufacturing. The concept was introduced in manufacturing to improve profits by reducing costs as opposed to relying solely on increased sales. If a company can eliminate waste and become more efficient, it can save money, which increases overall profits.

    While the roots of lean manufacturing can be traced back to the 1400s, Henry Ford first fully integrated the entire production process, creating something called flow production in the form of an assembly line.

    This was a revolutionary change in car manufacturing, but while Ford certainly enhanced flow, he didn’t leave much room for variety. In the 1930s and ‘40s, Japanese manufacturers Kiichiro Toyoda, Taiichi Ohno, and others at Toyota made a series of simple innovations that allowed them to provide both continuity in process flow and a wide variety of vehicles, creating the Toyota Production System.

    This form of lean production enabled the elimination of waste, reduced costs, increased efficiency, and made information management simpler and more accurate. Lean methodology was further distilled and explored in the books The Machine That Changed the World by James P. Womack, Daniel Roos, and Daniel T. Jones, and Lean Thinking by James P. Womack and Daniel T. Jones.

    The latter book also introduced the five key principles of lean:

    1. Identify Value
    2. Map the Value Stream
    3. Create Flow
    4. Establish a Pull System
    5. Seek Perfection

    Learn more in our article, Understanding Lean Agile and the 5 Lean Principles.

    Of course, lean thinking has evolved beyond manufacturing and has been adapted and applied to everything from healthcare to construction to logistics and distribution to government to software development.

    1. Increased efficiency ⏳

    The application of lean to business processes is all about reducing waste to increase efficiency. But how do you figure out which processes provide value?

    Once customer value is identified, teams can create a value stream map. Value stream mapping tracks each of the steps and processes to bring a product from inception to delivery. Organizing your processes visually where everyone can see them allows teams to clearly see what does and doesn’t provide value. If any steps or processes don’t bring value to the customer or are found to be otherwise wasteful, they are eliminated or reduced as much as possible.

    A team can’t be efficient if they’re wasting time on tired processes that don’t provide customer value. Adopting lean methods helps to get rid of those processes, so you can dedicate your team’s energy exclusively to the processes that do, thereby increasing your team’s value flow, efficiency, and productivity.

    2. Reduced bottlenecks 🛑

    A bottleneck or broken process, no matter how small, can totally derail a workflow or make it impossible to meet a deadline.

    With lean, tasks aren’t blindly or randomly assigned. Teams work together to ensure work is evenly distributed and deadlines are met. They discuss any potential bottlenecks in advance so they can be solved before they become a financial burden or delay work. Since capacity and WIP (work in progress) items are continually forecasted, monitored, and adjusted with lean, bottlenecks are anticipated in advance, every team member participates, and no one’s time is wasted.

    3. Fewer costs (and fewer surprises!) 💸

    Lean methodology: Fairly Oddparents Burn GIF

    Eliminating waste means saving money—no matter the industry. Overproduction, having too many materials to store, overhiring, and production bottlenecks are expensive and wasteful. These wastes can be eliminated with better management of processes and systems, enabling companies to always have the right number of employees, amount of materials, and working hours at any given time.

    Adopting the lean methodology means increasing efficiency, which benefits any company’s bottom line. Make sure every cost is accounted for and necessary to the production process by consistently reviewing your company’s work processes and eliminating any costs that don’t add value.

    4. Systems can adapt better and faster 🌎

    Businesses today must adapt faster than ever due to increasing customer demand, rapidly evolving technological advancements, and the COVID-19 pandemic.

    The larger the size of the organization, the harder it is to adapt. Long-running business systems were not designed to be flexible, so when adjustments need to be made, it may take months or years before the entire organization is on the same page.

    With lean, teams can better adapt. Lean systems aren’t as rigid, so it’s easier to make adjustments along the way, meaning teams will better adjust for unexpected circumstances. The lean methodology can help any business, no matter its size, adapt to changing times gracefully, as lean is the exact opposite of a set it and forget it process.

    5. Stakeholder visibility and strong customer relationships 💞

    The lean methodology leans into both stakeholder and customer needs, which results in a better end product. Progress in lean is measured based on the value delivered to the customer instead of the completion of tasks.

    With lean, customer value is paramount. Every project and task begins with considering the point of view of customers and putting yourself in their shoes. Feedback is gathered alongside product development instead of at the end to ensure new information is considered and that the final product will be exactly what the customer needs or wants.

    6. Continuous improvement mindset 🧠

    Lean is the enemy of the status quo. Lean demands the constant fine-tuning and refinement of processes and enables a continuous improvement mindset. It’s not a “set it and forget it” process, as lean is all about consistent process improvement. No matter how successful or efficient the company is, there is always room for improvement and new, innovative ways to bring value to the customer.

    This attitude instills a continuous improvement mindset in everyone involved on the team, whether it’s a small development team or an entire lean enterprise (SAFe). Teams can anticipate and expect regular feedback from leaders, managers, and stakeholders. With lean, innovations and iterations are less precious and more plentiful. The team continues to improve and fine-tune their skills and processes with each passing product.

    7. Increased team engagement 🤝

    High Five Ashley Olsen GIF

    Employee disengagement is expensive. Disengaged employees have higher absenteeism, lower productivity, and lower profitability — all of which can majorly drain a company’s resources. If a company’s culture doesn’t inspire employees to show up and do their best, that company is going to hemorrhage money every year until its bottom line bottoms out.

    A lean organization, on the other hand, puts teams on the frontline of product development. Under lean management, employees have direct and regular contact with managers about how their work is going and how the process could be improved. Since teams are more involved in the process, they are more engaged and more likely to actively participate, provide feedback, and buy into their work.

    Engaged employees are a company’s greatest asset. Bringing everyone into the process gives teams ownership over the outcomes, boosting their creativity as well as their accountability. Increased team engagement means enhanced efficiency, effectiveness, and team morale.

    You can apply the lean methodology anywhere to reduce waste and improve efficiency. Let’s recap. The top benefits of adopting lean include:

    1. Increased efficiency

    2. Reduced bottlenecks

    3. Fewer costs (and fewer surprises!)

    4. Better and faster systemic adaptation

    5. Stakeholder visibility and strong customer relationships

    6. Continuous improvement mindset

    7. Increased team engagement

    Agile made easy

    Easy Agile can help your agile team work better together to deliver for your customers. We have a suite of agile apps for Jira designed to put the customer first through every step of the product development process. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our plugins work with multiple agile frameworks, including Kanban and Scrum.

    If you work with Jira, you’ll find our lean tools especially helpful for improving the functionality of your workflows and enhancing team collaboration.

  • Workflow

    The State of Atlassian Report by Adaptivist (a summary)

    A couple of weeks ago, our partner Adaptavist released their State of the Atlassian Ecosystem Report which surveyed approximately 1,000 users of Atlassian tools and services. After reading the 50+ page document, I decided that the reports' insights were extremely valuable and worth sharing.

    You can also download the full report here. It is a fantastic read and incredibly interesting for anyone working within the Atlassian ecosystem.

    Key take-aways from Chief Information Officer at Adaptavist

    • Despite a turbulent year, Atlassian ecosystem continues to grow and evolve. This year the company surpassed $US500 million in quarterly revenue for the first time
    • For those who rely on Atlassian Server, the company’s decision to sunset its Server products has forced some soul searching and tough decision-making
    • Atlassian continues to focus on driving improvements around security, customisation, and feature parity
    • Let's open up collaboration across the ecosystem and find new ways to tackle the challenges that lie ahead.

    Key findings

    • Usage Up: Atlassian usage up despite decrease in IT spend overall. Including Jira, Access, Trello, Align and Advanced Roadmaps
    • Non Tech User Up: Increase in non-technical teams using Atlassian tools including Operations and Marketing.
    • Challenge: The biggest integration challenge organisations face is connecting Atlassian with other third-party apps such as Zoom, MS Office, Slack, Gitlab, Github, Salesforce.
    • Cloud: Atlassian Cloud adoption is increasing slowly but surely, 28% 2020 to 34% 2021. Server represents the majority of deployment followed by DC
    • Challenge: Customisation (57% concerned), app integration (48% concerned), cost, and feature functionality (43% concerned) are the main concerns about migrating to Atlassian Cloud
    • Changing deployment: 65% of respondents are expecting to change how they deploy Atlassian products in the next three years. Sunset of Server spurring this.
    • What people want more Automation - drives business processes, reduce operational costs and improve integration with tools
    • DevOps is Up: 27% of respondents developing a DevOps strategy in next 3 years. Adoption across verticals. Why? Automates workflows, faster development cycles, better coordination across teams, improved time to market. Why not? Lack of capability, inadequate training, budget (Same as the benefits that org’s can expect from DevOps!)
    • Agile Adoption Up, barriers to scaling efforts though: 67% of large enterprises (>5,000 employees) have high agile adoption intentions. Agile at scale adoption has increased from 10% in 2020 to 49% in 2021. Biggest barriers to agile at scale adoption: other priorities, current method working fine, unclear ROI. Why do org’s want to adopt agile at scale? Better team coordination, align strategy with delivery, increased visibility.