Stories by Easy Agile

If you have been running retrospectives for some time prior to 2020, you may be familiar with the follow agenda for a 1 hour session:

It is quite possible that as your team transitioned to working remotely from 2020 onwards, that retrospectives were still run in realtime but in a virtual setting using Zoom/Teams/Meet rather than in person.

Here at Easy Agile where we have flexible work arrangements, most team members usually spend 1-2 days a week in the office, though we now also have team members working interstate who are 100% work from home. As a result, all our teams really value their F2F meeting time whether it be in person or virtual, so we try to maximise that F2F time as much as we can for those important debates and conversations where the entire team can listen and participate in real time.

How Easy Agile uses TeamRhythm retrospectives to maximise team time

1. Team members can add items to the retrospective board anytime during the sprint

The team is reminded and encouraged to add items to the retrospective board at any time during the sprint, whenever it is top of mind. This can be done asynchronously without any time constraints. Items added like this tend to be worded better because it has not been rushed within the timebox of a traditional retro setting. Capturing the item when it’s top of mind ensures that these items are less likely to be forgotten when the team sits down together to run the retro at the end of the sprint.

2. The team self reviews the retro board during the sprint

The team can review the items on the retro board during the sprint and ping the author of a particular item if they are unclear as to the content of the item. With this feedback and over time, Easy Agile teams have learnt to write in a more specific manner where the item is less likely to be incorrectly understood.

3. Facilitators categorize items before the meeting

Grouping and sorting retro items during the meeting itself can often be a rushed and sometimes stressful event, especially if it is left to just the facilitator to do it while running the meeting at the same time. At Easy Agile, the nominated retro facilitator looks at the items of the board ahead of time and uses categories to label and group like-minded items together.

4. Face to face time are primarily for debate and action setting

Easy Agile retrospective meetings now mainly focus on reviewing and discussing those retrospective items already pre-labelled into specific categories, and deciding on what actions need to be taken in order to improve on future sprints.

The timing of a retrospective at Easy Agile now typically looks like this:

Wrapping it up

By encouraging the team to capture any lessons/thoughts they would like to share during the course of a sprint by capturing it as soon as it comes up on that sprint’s retro board, the majority of the time spent during the retrospective meeting at the close of a sprint focuses on meaningful conversations, ideation, candid feedback and debates and more thoughtful actions.
Less time is wasted with the team sitting silently trying to recall what worked or didn't work during the last two weeks and then having to type it out quickly and have it make sense to the rest of the team.

Just one more thing…

By the time you read this, we will have provided users with the ability to add items to a retrospective board directly from the Jira issue viewer, so now the friction to add a retrospective item is reduced by one less step.

And we also plan to provide the option to display any outstanding retrospective actions from previous sprints on the current retro board.

How do you and your teams run retros? Do you have any tips that you would like to share with us? We would love to learn from you as well. Please email us at hello@easyagile.com with subject: Retro tips.

Retrospectives help create an environment where team members can freely share their wins and challenges. By encouraging this feedback, you get critical insights into what can be improved in the next iteration. But while it sounds straightforward in theory, many teams struggle to make agile retrospectives work in practice.

So if we know team retrospectives can be a great way to drive continuous improvement and deliver value – why do so many teams struggle to get it right?

The slippery slope to becoming a tick box exercise

According to Easy Agile Product Marketing Manager Tenille Hoppo, the struggle with retrospectives often lies behind two key challenges. "If you’re having the same discussions week after week, and the team can’t see anything changing, then people can become fatigued, disengaged, and bored," said Tenille. "Over time, retrospectives become less respected and less effective as a process, and eventually become nothing more than a tick box exercise".

"Then there’s the challenge around capturing actions in real-time," said Tenille. "We’ve all been guilty of having great ideas while working on something, but by the time the next retrospective comes around, the idea is gone".

The challenges around keeping retrospectives fresh, productive, and integrated with the work in Jira are behind the development of Easy Agile TeamRhythm, an app designed to overcome these common issues and help teams deliver value to their customers more quickly.

Integrating user story maps and retrospectives

"We believed if we could integrate the retrospective process right alongside the work in Jira, teams would be better able to deal with the issues blocking their progress and work more effectively," said Tenille. "So, we mapped out the groundwork as part of an Inception Week project, and soon after that, Easy Agile TeamRhythm was born".

Easy Agile TeamRhythm replaces our first app, Easy Agile User Story Maps, and integrates team user story maps with team retrospective boards. The user story maps are used for planning and managing work (including sprint planning and backlog refinement), while retrospective boards help teams do that work better. "It made sense to build on the sprint planning and backlog refinement capabilities of Easy Agile User Story Maps and introduce retrospective boards to capture and collate ideas for improvement," said Tenille. "With retrospectives colocated where work is managed in Jira, you can turn action items into Jira issues and schedule work, ensuring retrospectives are effective and valuable".

Elevating retrospectives with Easy Agile TeamRhythm

Easy Agile TeamRhythm supports teams from planning through to release and retrospectives. It covers user story mapping, sprint planning, version planning, backlog refinement, and team retrospectives.

By featuring a team retrospective board integrated alongside your Jira boards, agile teams can use the app to:

Capture feedback in real-time

Team members can capture feedback quickly and easily as they do their work. As a result, feedback and ideas don’t get lost and, instead, are there waiting for you when you run the next retrospective.

Combat fatigue with templates

You can access different templates to help change the format of retrospectives, frame things differently, and keep team members interested. This can also help teams see things from different angles and come up with new ideas.

Current templates include:

• Foundation
  A highly customizable template based on the Start, Stop, & Continue model. The team looks at looks at the actions they want to introduce, those that aren't working, and what can continue into the next cycle.
• Get Rhythm
  A music-themed template using the 4 L’s retrospective format, to understand what is “Loved, Learned, Loathed, and Longed for”. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of.
• Space Mission
  A stellar-themed template based on the Sailboat retrospective format, examining the approaches that inhibit progress, or reap desirable outcomes, and establish a direction for planning the next iteration.
• Rose Blossom
  A rose-themed template based on the Starfish model, that involves rating the efficacy of action items to determine the methodologies they should keep, discard, and apply in the next round.

Improve the next iteration by applying insights

The ‘Actions’ column is where you turn feedback into tangible actions and create in-built accountability. In just two clicks, you can turn an action item into a Jira issue that is automatically added to your backlog. You can then assign an owner and schedule it into an upcoming sprint or release.

“We’ve improved our communication and team alignment, which has helped give us faster results”.

Casey Flynn, Adidas

Make your next release better

"Agile isn’t about wringing every ounce of work you can get from your team, and it’s also not about wasting time in unproductive meetings that don’t drive an outcome," said Tenille. "With Easy Agile TeamRhythm, we provide the framework and functionality to help share learnings, plan solutions, and take action. And as teams focus on incremental improvements, they can start working better together, feel happier in their role, and deliver better outcomes".

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

Like to hear more?

Tenille presented on this topic in a webinar with Atlassian Solution Partner Almarise. Watch the full presentation below.

‍

The seventh principle of the Manifesto for Agile Software Development is:

Working software is the primary measure of progress.

Not story points, not velocity, not estimates: working software.

Jason Godesky
Better Programming

Estimation is a common challenge for agile software development teams. The anticipated size and complexity of a task is anything but objective; what is simple for one person may not be for another. Story points have become the go-to measure to estimate the effort involved in completing a task, and are often used to gauge performance. But is there real value in that, and what are the risks of relying too heavily on velocity as a guide?

Agile estimation

As humans, we are generally terrible at accurately measuring big things in units like time, distance, or in this case, complexity. However, we are great at making relative comparisons - we can tell if something is bigger, smaller, or the same size as something else. This is where story points come in. Story points are a way to estimate relative effort for a task. They are not objective and can fluctuate depending on the team's experience and shared reference points. However, the longer a team works together, the more effective they become at relative sizing.

The teams that I coach have all experienced challenges with user story estimation. The historical data tells us that once a story exceeds 5 story-points, the variability in delivery expands. Typically, the more the estimate exceeds 5 points, the more the delivery varies from the estimate.

Robin D Bailey, Agile Coach, GoSourcing

Scale of reference

While story points are useful as an abstraction for planning and estimating, they should not be over-analyzed. In a newly formed team, story points are likely to fluctuate significantly, but there can be more confidence in the reliability of estimations in a long-running team who have completed many releases together. Two different teams, however, will have different scales of reference.

At a company level, the main value I used to seek with story points was to understand any systemic problems. For example, back when Atlassian released to Server quarterly, the sprints before a release would blow out and fail to meet the usual level of story point completion. The root cause turned out to be a massive spike in critical bugs uncovered by quality blitz testing. By performing better testing earlier and more regularly we spread the load and also helped to de-risk the releases. It sounds simple looking back but it was new knowledge for our teams at the time that needed to be uncovered.

Mat Lawrence, COO, Easy Agile

Even with well-established teams, velocity can be affected by factors like heightened complexity with dependencies scheduled together, or even just the average number of story points per ticket. If a team has scheduled a lot of low-complexity tickets, their process might not handle the throughput required. Alternatively having fewer high-complexity tickets could drastically increase the effort required by other team members to review the work. Either situation could affect velocity, but both represent bottlenecks.

Any measured change in velocity could be due to a number of other factors, like capacity shifting through changes in headcount with team members being absent due to illness or planned leave. The reality is that the environment is rarely sterile and controlled.

Relative velocity

Many organizations may feel tempted to report on story points, and velocity reports are readily available in Jira. Still, they should be viewed with caution if they’re being used in a ‘team of teams’ context such as across an Agile Release Train. The different scales of reference across teams can make story points meaningless; what one team considers to be a 8-point task may be a 3-point task for another.

To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.
…
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.

Ron Jefferies
Co-Author of the Manifesto for Agile Software Development
Story Points Revisited

Seeking value

However, story points are still a valuable tool when used appropriately. Reporting story points to the team using them and providing insights into their unique trends could help them gain more self-awareness and avoid common pitfalls. Teams who are seeking to improve how they’re working may wish to monitor their velocity over time as they implement new strategies.

Certainly, teams working together over an extended period will come to a shared understanding of what a 3 story point task feels like to them. And there is value in the discussion and exploration that is needed to get to that point of shared understanding. The case for 8 story points as opposed to 3 may reveal a complexity that had not been considered, or it may reveal a new perspective that helps the work be broken down more effectively. It could also question whether the work is worth pursuing at all, and highlight that a new approach is needed.

The value of story points for me (as a Developer and a Founder) is the conversations where the issue is discussed by people with diverse perspectives. Velocity is only relatively accurate in long-run teams with high retention.

Dave Elkan, Co-CEO, Easy Agile

At a company level, story points can be used to understand systemic problems by monitoring trends over time. While this reporting might not provide an objective measure, it can provide insights into progress across an Agile Release Train. However, using story point completion as a measure of individual or team performance should be viewed with considerable caution.

Story points are a useful estimation tool for comparing relative effort, but they depend on shared points of reference, and different teams will have different scales. Even established teams may notice velocity changes over time. For this reason, and while velocity reporting can provide insights into the team's progress, it must be remembered that story points were designed for an estimation of effort, rather than a measure. And at the end of the day, we’re in the business of producing great software, not great estimates.

Looking to focus your team on improvement? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives linked to your agile board in Jira, to improve your ways of working and make your next release better than the last. Turn an action item into a Jira issue in just a few clicks, then schedule the work on the user story map to ensure your ideas aren’t lost at the end of the retrospective.

Many thanks to Satvik Sharma, John Folder, Mat Lawrence, Dave Elkan, Henri Seymour, and Robin D Bailey for contributing their expertise and experience to this article.

We are thrilled to announce that Easy Agile has successfully achieved SOC 2 Type II compliance, a significant milestone in our unwavering commitment to maintaining high standards of security and privacy.

What is SOC 2 Type II Compliance?

System and Organization Controls (SOC) 2 is a widely recognized security standard developed by the AICPA that specifies how organizations should manage customer data. A SOC 2 report is often the primary document that security departments rely on to assess a service provider's ability to maintain adequate security.

Service providers like Easy Agile voluntarily undergo a rigorous audit and assessment to ensure their security controls meet AICPA’s Trust Services Criteria, including:

• Security
• Availability
• Processing integrity
• Confidentiality

SOC 2 compliance comes in two forms: A SOC 2 Type I report describes the design of a service provider’s system controls to meet relevant trust criteria as of a specific point in time, while a SOC 2 Type II report details the operational effectiveness of those systems controls to perform as designed over a specified period. An independent auditor, Johanson Group, has reviewed and certified that our processes, procedures, and controls are properly designed to meet the SOC 2 standards.

What does this mean for you?

Our achievement of SOC 2 Type II compliance means that when you use Easy Agile's services, you can continue to do so with the confidence that we have robust controls in place to secure your data. We believe that security is a shared responsibility, and this milestone is part of our ongoing effort to provide transparent and secure practices that support your business.

We want to thank you for your trust and support in Easy Agile. Your data security and privacy are our top priorities, and we are committed to delivering services that not only meet but exceed industry standards.

When is ISO 27001 coming?

Now that we've completed our SOC 2 Type II compliance we'll be setting our sights on ISO 27001 compliance in the next 12 to 18 months.

Where can I learn more?

Visit our Trust Report to access security reports and monitoring.

For any questions or more information about our SOC 2 Type II compliance and what it means for you, please feel free to reach out to our team at security@easyagile.com.

We are thrilled to announce that Easy Agile has successfully achieved SOC 2 Type 1 compliance, a significant milestone on our unwavering commitment to maintaining high standards of security and privacy.

What is SOC 2 Type 1 Compliance?

According to our compliance partner, Vanta:

”SOC 2 is the most sought-after security framework for growing SaaS companies. SOC 2 attestation demonstrates your organization’s ability to keep customer and client data secure.”

Service Organization Control (SOC) 2 is a widely recognised auditing standard designed to ensure that service providers manage your data appropriately. SOC 2 compliance is particularly relevant for technology and cloud-based companies that store customer data as it requires them to establish and maintain strict information security policies and procedures.

The "Type 1" designation indicates that our systems and controls have been evaluated and tested at a specific point in time. Achieving SOC 2 Type 1 compliance means that an independent auditor, Johanson Group, has reviewed and certified that our processes, procedures, and controls are properly designed to meet the SOC 2 standards for security, availability, processing integrity, confidentiality, and privacy.

What this means for you

Atlassian recommended we partner with Vanta for our SOC 2 compliance as Vanta are a leading trust management platform serving software companies like Easy Agile.

Our achievement of SOC 2 Type 1 compliance means that when you use Easy Agile's services, you can do so with the confidence that we have robust controls in place to secure your data. We believe that security is a shared responsibility, and this milestone is part of our ongoing effort to provide transparent and secure practices that support your business.

We want to thank you for your trust and support in Easy Agile. Your data security and privacy are our top priorities, and we are committed to delivering services that not only meet but exceed industry standards.

When is SOC 2 Type 2 coming?

We are currently in the audit period for Type 2 compliance. We will update this page when we have achieved Type 2.

We intend to seek ISO 27001 compliance once we have achieved SOC 2 Type 2 compliance.

Where can I learn more?

Visit our Trust Report to access security reports and monitoring.

For any questions or more information about our SOC 2 Type 1 compliance and what it means for you, please feel free to reach out to our team at security@easyagile.com.

Trust Report

View our trust report hosted by our compliance partner, Vanta.

Go to trust report

What is agile PI planning?

PI Planning is a critical event for agile teams to set a clear direction for the upcoming Program Increment or Planning Interval (SAFe 6.0). It helps teams to identify potential risks, assess impact and effort, and benefit from coordination and alignment around priorities and milestones

PI Planning at its core promotes agility. By fostering closer alignment between stakeholders and development teams, it enables effective decision-making, promotes transparency, and encourages adaptive planning. This iterative approach empowers teams to continuously refine their strategies, ensuring successful outcomes and delivering value to stakeholders.

As a result it is necessarily a collaborative process - that ultimately optimizes the delivery of value by blending predictability and agility, while maximizing team efficiency and productivity. But we often overlook how to make the PI Planning event itself more agile.

While an important ceremony for any organization aiming to stay ahead of the competition in today's market - it can also be daunting. From figuring out the right approach to creating feedback loops that keep individuals focused and motivated, there are plenty of complexities when it comes to mastering agile PI Planning.

Additionally in today's distributed landscape, agile teams face unique challenges when it comes to effective collaboration and planning. The key to agile PI Planning agile requires a shift towards more flexible, collaborative and efficient processes and environments.

The key to agile PI Planning requires a shift towards more flexible, collaborative and efficient processes and environments.

This blog post will provide an overview on what challenges there are to agile PI Planning in Jira, and how you can overcome them using Jira together with Easy Agile programs.

Top 3 challenges of agile PI Planning in Jira

1. Collaborating across tools and timezones

Real-time collaboration is essential for agile PI planning, but it is challenging to implement in a remote or distributed environment. The pandemic accelerated the shift to a remote workforce, creating new challenges for PI planning.

Agile teams in Jira striving to effectively plan often face a version of these challenges. One of the most common obstacles teams face is the lack of a visual, intuitive platform that can accommodate the dynamic nature of agile planning. Teams end up using physical boards or switching tools, requiring manual work to implement back into Jira, which can disrupt the flow of work and lead to inefficiencies.

2. Misalignment and miscommunication

PI planning aims to break down silos and bring together multiple teams working on the same sprint. However, with so many teams involved in the planning process, it is common for teams to prioritize their specific goals or issues, leading to inefficient communication. The challenge lies in getting everyone to speak the same language, work to a shared understanding of priorities and ensuring they are all on the same page.

Another hurdle is accommodating cross-team dependencies. Agile teams often work closely with other teams across their organization, and their workstreams are often intertwined. Teams need a straightforward way to visualize these dependencies, to anticipate blockers and plan effectively. What’s more, the process of creating and managing dependencies across multiple teams can become complex and time-consuming.

3. Not being able to see the bigger picture

Lastly, long-term or bigger picture planning can be a struggle. It is easy for PI planning to become too focused on processes and lose sight of the bigger picture where we need to align our goals, objectives and capabilities. In short, it is crucial to align PI planning with the business and customer needs. The planning process should aim to deliver value to customers, build on existing success, and address new challenges. Achieving this requires collaboration, discipline, and creativity.

Teams need to be able to see the big picture and plan work in alignment with the business’ goals and strategy. to Without it, the disconnect can make it challenging for teams to align their day-to-day tasks with their long term goals. The lack of a dedicated space for capturing objectives and their business value can also lead to misalignment and missed opportunities.

So what is needed for agile PI Planning?

When looking for an add-on or additional solution to work with Jira to solve for agile PI Planning, it is key to find one that provides:

1. A shared view and understanding to maintain transparency and alignment for the ART, especially program-level visibility
2. Connection between business priorities and the work of delivery teams
3. Dependency management
4. Real-time collaboration
5. A tool that everyone can use and access to continue collaboration

Agile PI Planning with Jira and Easy Agile Programs

By using Jira and Easy Agile Programs for your PI planning, you can ensure that your agile workflows are streamlined, collaborative, and in line with your strategic objectives. Easy Agile Programs empowers teams to adapt quickly to changes, manage risks better, and deliver value more efficiently. What’s more, it is a native app embedded in Jira, meaning there is little to no configuration as the tool is set up using your underlying Jira data.

Read on to find out how it helps solve the challenges of agile PI Planning specifically.

1. A shared space to collaborate and iterate

The Program Board (ART Planning Board)

Remember, the key to agile planning is flexibility and collaboration, and the ability to adjust plans as necessary. At the same time, it is important to make the process as easy and intuitive as possible and to avoid wasting time on administrative tasks.

If your teams are in Jira, the first place to start is by creating an environment in Jira so there’s less manual overhead and cognitive load for everybody to be able to participate and for planning to translate into delivering. Easy Agile Programs digitises the SAFe Program Board (ART Planning Board for SAFe 6.0) which provides transparency to all members of the ART.

It is built using native Jira issuse and boards, and acts as a single source of truth during and beyond planning. It’s here we have a holistic view of the work we’ve committed to as an ART and an indication of whether we’re on track to achieve it, with the flexibility of making adjustments without leaving the tool should we need to.

The digitised Program Board in Easy Agile Programs is highly visual and also filterable, allowing you to focus in on specific teams, status of issues, or features/epics for focussed ART, PO and coach syncs during the Program Increment/Planning Interview.

The Team Planning Board

Unlike other tools, teams have a dedicated Team Planning Board for team breakout sessions. Here teams can break down features into stories and schedule them within sprints, estimate capacity and plan work collaboratively within and across teams. Given that teams have access to their own backlog and are scheduling work onto their own board in Jira, there is no downtime or double handling.

2. Anticipating and visualizing dependencies

Visualizing and managing program risks and dependencies is not only crucial for effective Planning - but it is also a clear indicator of how well we stay aligned as teams within the ART. Easy Agile Programs is a powerful way to visualize dependencies, enabling teams not only to create, identify, and understand the health of dependencies, but also to resolve dependencies across multiple teams. This fosters collaboration, breaks down siloes and mitigates potential roadblocks to progressing the work.

On the Team Planning Board

When teams are at the stage of breaking down features into stories or epics, they can easily create and understand dependencies within and across teams.This means that work is never created without understanding how it aligns or conflicts with other teams in the ART to maintain alignment. Creating dependencies is easily done through drag and drop:

On the Program Board

Identifying dependencies and potential risks to scheduling work is a critical part of PI Planning. Aside from visible dependency lines, Easy Agile Programs also visualises the health of those dependencies. Green means the dependency is healthy, orange means it is at risk, and red indicates a conflict. Black dependency lines indicate dependencies external the PI or Program - critical for the Release Train Engineers to address between ARTs.

This is all visible on the Program Board where we can also filter by dependencies:

Want to learn more about Easy Agile Programs?

On demand demo

Watch now

3. Bigger picture planning and alignment

Third level hierarchy

Connecting the work of the teams to what the business cares about is instrumental in the delivery of value. Easy Agile Programs provides the connective tissue between higher level business priorities and initiatives with third level hierarchy, making it easy to understand what is scheduled to deliver against business priorities and how it is progressing.

PI Objectives

From the Team Planning Board  can easily create draft PI Objectives and link them to Jira issues, ensuring alignment and transparency with business value. This is a critical part of linking what the team is working on to broader business objectives, and Easy Agile Programs literally links the issues to these objectives so that we can filter the work by objective.

Agile planning is iterative, and plans often require adjustments.

Can I still use Easy Agile Programs for planning if I'm not practising SAFe?

Absolutely. Easy Agile Programs is not just for teams practising the SAFe methodology.

The tool is flexible and adaptable, making it equally beneficial for any agile team that values interactive, visual planning. Regardless of the specific framework you use, Easy Agile Programs facilitates clear communication, makes it easier to manage dependencies, provides a shared view of team capacities and progress, and aligns teams with overarching business objectives.

This way, whether you're practicing Scrum, Kanban, or your own unique blend of agile methodologies, you can still leverage the power of Easy Agile Programs to foster a more collaborative and efficient planning process.

‍

One question that often arises is, “What are the indicators of a highly effective Scrum Master?" When striving to become an exceptional Scrum Master, consider the following:

• Identify Repeated Mistakes: While occasional mistakes are expected, it is important for the Scrum Master to collaborate with the team to identify recurring mistakes. By implementing policies and practices, the team can prevent these mistakes from happening again.
• Address Systemic Issues: If the team consistently encounters the same issues, the Scrum Master must recognize the presence of systemic problems. Working with the team, the Scrum Master can establish countermeasures to prevent these issues from reoccurring.
• Measure Improvements Over Time: Are we continuously improving as a team? Assess whether the team is more effective now compared to prior periods, such as 6, 9, and 12 months ago. Similarly, consider if the team will be better in the future. If progress stalls, it may be necessary to reevaluate the effectiveness of the Scrum Master.

If your team is progressing across all three of these areas, that’s a great sign that the Scrum Master is effective and that the team is learning and improving.

To drive continuous improvement, the Scrum Master should utilise the retrospective. The retrospective is a Scrum event conducted after the Sprint Review to evaluate and adapt the process and the team's ability to deliver products effectively. During this session, the Scrum Master guides the team in celebrating successes and exploring areas for improvement.

Outlined below is a 7-step checklist used by Scrum Masters during retrospectives to address problems:

1. Discuss the Problem: In the retrospective, the Scrum Master facilitates a discussion to identify the main challenges faced by the team.
2. Assess Impact: Determine the urgency and impact of the problem. Immediate action may be required for highly impactful issues, while less pressing matters can be addressed later.
3. Identify Root Causes: Understanding the root cause allows the team to gain deeper insights and generate potential solutions.
4. Generate Solutions: Once a significant problem is recognized, the Scrum Master guides the team in brainstorming solutions to address the issue.
5. Implement Solutions: This step is carried out in the subsequent retrospective. The Scrum Master ensures that the proposed solutions are tried and tested.
6. Evaluate Initial Results: Assess the effectiveness of the implemented solution. Did it fix the problem, make it worse, or have no effect?
7. Determine Next Steps: Based on the results, decide whether the problem is resolved or if further action is needed. This may involve continuing with the current solution or pivoting to a different approach.

For example, let's consider a team struggling with high defect rates. Their defect rates surpass both the organisation's average and industry standards. Here's how the 7-step checklist could be applied:

Step 1: In the retrospective, the Scrum Master raises the issue of high defect rates for discussion.

Step 2: The Product Owner shares feedback from the help desk team, highlighting customer complaints and the negative impact on sales.

Step 3: After deliberation, the team recognizes that many defects are missed during manual testing and identifies the lack of test automation as a contributing factor.

Step 4: A team member with experience in automated testing proposes implementing unit-level automated testing practices.

Step 5: In the subsequent retrospective, the team reports applying the new unit testing practices to all their work during the sprint.

Step 6: The team acknowledges that the automated tests identified six defects that would have otherwise been missed.

Step 7: The team agrees to continue using automated unit testing practices and plans to expand to integration-level testing as more of the codebase is covered.

By utilising this 7-step checklist, Scrum Masters can effectively leverage retrospectives to address recurring mistakes, resolve ongoing issues, and foster continuous growth and improvement within their teams.

Many organizations, especially those in highly regulated industries, struggle to manage large-scale projects. SAFe, or the Scaled Agile Framework, can provide a solution. (OR That's where SAFe, or the Scaled Agile Framework, comes into play.)

SAFe is a framework designed to help businesses make sustainable changes on a large scale. It offers training and guidance for implementing agile practices across the enterprise, whether it's at a small team level, department level, or throughout the entire organization.

In this blog post, we will delve deeper into the benefits of implementing SAFe, focusing specifically on how it can be utilized within the financial services industry to create a lean enterprise.

Benefits of SAFe for financial services

SAFe (Scaled Agile Framework) is an incredibly valuable approach for organizations looking to enhance their operations. By adopting SAFe, financial services firms can achieve numerous benefits that are specific to their industry.

1. Business Agility: SAFe enables financial services firms to become more adaptable and responsive to market dynamics. By adopting SAFe practices at an enterprise level, organizations can foster a culture of continuous improvement, allowing them to quickly adapt to changing customer demands, regulatory requirements, and emerging technologies.
2. Enhanced Customer Experience: In today's competitive financial services landscape, providing exceptional customer experiences is paramount. SAFe promotes customer-centricity by encouraging regular feedback loops with customers throughout the development process. This allows financial institutions to gather insights, identify pain points, and rapidly iterate on their products and services, ensuring they meet the evolving needs and expectations of their customers.
3. Accelerated Time-to-Market: Time is of the essence in the financial industry. SAFe empowers organizations to speed up their time-to-market by breaking down silos and fostering collaboration between departments. By leveraging agile practices, financial services firms can respond quickly to market opportunities, launch innovative solutions faster ensuring they are first to seize market opportunities
4. Risk Mitigation: Compliance and risk management are critical considerations for financial services organizations. SAFe provides a structured governance framework that incorporates compliance requirements into the development process. This ensures that products and services adhere to regulatory standards.
5. Improved Operational Efficiency: Financial services firms deal with significant complexity, from managing intricate financial systems to addressing regulatory demands. SAFe helps optimize operational efficiency by promoting transparency, communication, and continuous improvement. By implementing Lean principles and agile practices, organizations can eliminate waste, optimize processes, and enhance overall operational performance.
6. Employee Engagement and Empowerment: SAFe emphasizes the empowerment of teams, fostering a culture of collaboration, innovation, and continuous learning. This approach leads to increased employee engagement, as team members feel more involved in decision-making processes and have a sense of ownership over their work. The result is a motivated and empowered workforce that drives organizational success.

Visualizing Dependencies for Seamless Collaboration and Timely Delivery

In the intricate world of SAFe, covering every aspect can be overwhelming. For the purpose of this blog, let's focus on a specific use case.

The financial services industry often deals with complex projects involving multiple teams and stakeholders. In such scenarios, visualizing and understanding dependencies among teams becomes critical. This is where the SAFe program board comes in. It acts as a centralized space for teams to effectively visualize, manage dependencies, and progress transparently.

Consider the example of Easy Agile Bank, preparing to launch its self-service banking platform. Various teams, including software, marketing, and customer success, collaborate to make this launch successful. To ensure a seamless rollout, understanding team dependencies and efficient work scheduling are paramount. The goal is to prevent bottlenecks that could delay the launch of the new self-service banking app.

Let’s take a closer look at what this might look like. Below you can see the Team Planning board in Easy Agile Programs for the Software team. The red, yellow, green and black lines indicate dependencies. Some dependencies exist within the software team, while others are cross-team dependencies with the marketing team.

The color of the dependency lines reflects their health status. A red dependency represents a conflict, yellow indicates at risk, green signifies a healthy state and black indicates external dependencies outside the current view, such as work in the backlog or in an other Program Increments. To avoid bottlenecks, you need to address the red dependencies and the yellow where possible.

With Easy Agile Programs, visualizing dependencies becomes effortless. Teams can act swiftly and adjust plans accordingly to prevent delays in the app launch. For instance, the software team identifies a red dependency with the marketing team regarding the live chat system. While the software team plans to set it up in Sprint 2, the marketing team don’t plan on mapping out the live chat experience and messaging until Sprint 3. The dependency line serves as a visual indicator, prompting teams to discuss and reschedule work.

After a brief discussion, the software team decides to reschedule the live chat setup to Sprint 4. As a result, the dependency line turns green, indicating a smooth progress and successful avoidance of a potential bottleneck.

“When I would ask colleagues how long it would take to untangle and understand dependencies, they would suggest a week. With Easy Agile Programs, it took us three minutes”.

Stefan Höhn, NFON

Harness the Power of the SAFe Program Board

Overall, the program board can help teams prioritize their work and make informed decisions about resource allocation. By visualizing dependencies, teams can identify critical path items and focus their efforts on the most important tasks that need to be completed first. This ensures that teams are working in a coordinated, transparent manner and reduces the risk of unnecessary delays or conflicts.

The SAFe program board acts as a valuable tool for teams to effectively manage dependencies, promote collaboration, and achieve alignment in large-scale agile projects.

Easy Agile Programs allows teams to identify and create dependencies effortlessly, empowering teams to navigate the complex financial services landscape with ease.

JOIN A DEMO

‍