Agile Transformation Archives

Blog

Your Ultimate Guide to Agile Transformation

By: Agile Velocity | May 03, 2024 | Agile Metrics, Agile Technical Practices, Agile Tools, Agile Transformation, Organizational Agility

Agile has been shown to shorten time-to-market, increase quality, instill predictability, improve customer satisfaction, and create an overall happier working culture.

Agile Transformation involves all levels of the organization and applies Lean-Agile principles to business processes, practices, tools, operations, and culture. Agile Transformations require distinct parts of the organization to partner, collaborate, and work together to achieve common goals.

A company may choose to undergo an Agile Transformation for various reasons, each aimed at achieving specific business outcomes and addressing organizational challenges. Here are some benefits an organization can gain by embarking on an Agile Transformation:

This article covers

Common transformation challenges and how to avoid them
Defining your transformation strategy
How to create your transformation roadmap
Options for rolling out Agile in your organization
Metrics to measure the impact of agility on your business goals
Tools and technologies to consider
Examples of agility in action

Key Terminology

Before we dive in it is important to understand the difference between a few key terms.

Agile Transformation: Agile Transformation refers to the process of transitioning an organization from traditional, hierarchical, and rigid ways of working to Agile methodologies and practices. It involves reshaping organizational structures, processes, culture, and mindset to embrace Agile principles such as iterative delivery, customer collaboration, and continuous improvement.

Agile Implementation: Agile implementation refers to the tactical execution of Agile methodologies and practices within an organization. Agile implementation typically focuses on team-level adoption of Agile practices, emphasizing principles such as self-organization, cross-functional collaboration, and incremental delivery.

Organizational Agility: Organizational agility refers to an organization’s ability to adapt, respond, and thrive in a rapidly changing and uncertain environment. Organizational agility involves fostering a culture of collaboration, innovation, and continuous improvement, empowering employees to experiment, learn, and adapt to change effectively.

Business Agility: Business agility extends the concept of organizational agility to focus specifically on the ability of a business to adapt and respond to market dynamics and customer needs rapidly. Business agility encompasses aspects such as product innovation, customer-centricity, cross-functional collaboration, and adaptive strategy execution.

Common Transformation Challenges

While Agile Transformation can seem straightforward, it is easy to get stuck by common and costly pitfalls. Here are the top 5 things we see get in the way of organizational agility:

Focusing on Practices over Outcomes
Agile is not just about adopting specific practices like stand-up meetings or sprints; it’s about embracing a mindset of iterative delivery, customer collaboration, and continuous improvement to deliver value to customers efficiently. Focusing solely on practices without considering their alignment with desired outcomes can lead to superficial adoption, where teams go through the motions without realizing the true benefits of agility.

Focus Only on Team Level
Agile Transformation initiatives sometimes focus exclusively on individual teams, neglecting the broader organizational context. While transforming individual teams is essential, true organizational agility requires alignment and collaboration across departments and levels of the organization. Siloed transformation efforts at the team level can result in suboptimal outcomes and fail to address systemic issues that hinder agility at the organizational level.

Training Without Coaching
Providing training on Agile principles and practices is crucial for building awareness and common understanding among teams and individuals. However, training alone is often insufficient to drive meaningful behavior change and sustained adoption of Agile practices. Coaching complements training by providing ongoing support, guidance, and feedback to teams as they navigate the complexities of Agile adoption.

Lack of Business Engagement
Agile Transformations require active engagement and support from business stakeholders. Without strong business engagement, teams may struggle to prioritize and deliver value-aligned initiatives, resulting in a disconnect between business objectives and Agile delivery.

Not Optimizing Across Entire Value Stream
The value stream involves all activities and processes from concept to customer delivery, aiming to add value at every step. This includes ideation, design, development, production, delivery, and post-sales support. Through analysis and refinement, organizations eliminate inefficiencies, ensuring smoother workflows, shorter lead times, and higher-quality outputs.

Addressing these transformation challenges requires a holistic approach that emphasizes outcomes over practices, considers the entire organizational ecosystem, provides coaching support, fosters business engagement, and optimizes the value stream for continuous delivery of value to customers. To learn more transformation pitfalls and how to avoid them, download our free white paper, 8 Common Pitfalls of An Agile Transformation.

If some of these pitfalls sound familiar, we’re here to help you get out of them and on the path to success.

Agile Transformation Strategy

In today’s fast-paced and ever-evolving business landscape, agility isn’t just a buzzword; it’s necessary for survival. Companies across industries recognize the importance of embracing agility to stay competitive, innovate, and respond swiftly to market changes. Agile Transformation is a holistic approach to redefining how organizations operate, collaborate, and deliver value.

Agile Transformation is more than just implementing Agile methodologies; it’s a cultural shift that permeates every level of an organization. However, embarking on this journey without a well-thought-out strategy can lead to pitfalls and setbacks. To navigate the complexities of Agile Transformation successfully, organizations need a clear and comprehensive strategy.

While the actual practices you choose to implement will vary based on the goals and circumstances of your organization there are a few key steps to follow:

Define Business outcomes: Before diving into Agile Transformation, it’s crucial to define clear objectives. What are the desired outcomes? Is the goal to improve time-to-market, enhance product quality, or foster innovation? By articulating specific objectives, organizations can align their transformation efforts and measure progress effectively.
Measure Progress and Impact: Define key performance indicators (KPIs) and metrics to track the progress and impact of the Agile Transformation. Whether it’s increased delivery speed, improved customer satisfaction, or higher employee engagement. Establish metrics that align with organizational goals, regularly assess the effectiveness of Agile capabilities, and adjust strategies as needed.
Create a Vision: Develop a compelling vision for the future state of the organization post-transformation. Articulate how Agile principles will drive value, improve efficiency, and enhance customer satisfaction.
Gain Leadership Support: Agile Transformation is as much about culture as it is about processes. Leadership buy-in is crucial for driving cultural change, allocating resources, and removing organizational barriers. Ensure that leaders understand the benefits of Agile and their role in championing the transformation effort.
Assess Current State: Understanding the current state of the organization is essential for crafting an effective transformation strategy. This involves assessing existing processes, culture, and organizational structure. Identifying strengths, weaknesses, and areas for improvement lays the foundation for targeted interventions.
Determine Tailored Approach: One size does not fit all when it comes to Agile Transformation. Organizations vary in size, industry, and complexity, necessitating a tailored approach. Whether adopting Scrum, Kanban, or a hybrid Agile framework, it’s essential to adapt practices to suit the organization’s unique context and requirements.
Empowerment and Training: Empowering teams with the skills and knowledge required to embrace Agile practices is critical. Provide training and coaching to equip teams with the tools and techniques they need to sustain adoption and continuous improvement.
Implement Feedback Loops: Feedback loops are the lifeblood of Agile Transformation. Establish mechanisms for collecting feedback from teams, stakeholders, and customers regularly. Use this feedback to identify bottlenecks, address issues, and refine processes iteratively.
Change Management: Implement effective change management practices to navigate the organizational transition to Agile Methodologies successfully. Communicate the reasons for change, involve employees in the decision-making process, address resistance, and provide support and resources to help employees adapt to new ways of working.
Iterate and Evolve: Agile Transformation is an iterative process, much like Agile development itself. Rather than a big-bang approach, organizations can adopt a phased implementation strategy. Start with pilot projects or teams to test Agile practices, gather feedback, and iterate based on learnings before scaling across the organization.

Once your transformation strategy is in place it is time to sequence the journey into a transformation roadmap.

Creating Your Agile Transformation Roadmap

Embarking on an Agile Transformation can be daunting without a clear roadmap to guide the way. An Agile Transformation roadmap visualizes the sequential journey and major milestones involved in the Agile Transformation process.

When sequencing departments and teams in an Agile Transformation, it’s essential to consider factors such as organizational readiness, dependencies, and impact on business operations. Prioritize departments based on strategic importance, existing pain points, and potential for quick wins. Through this sequencing, organizations can strategically introduce Agile practices across departments and teams, fostering a culture of agility and driving business success.

In addition to sequencing which teams, departments, or product lines are adopting Agile, you can also develop an Agile Transformation roadmap based on organizational capabilities needed to achieve overall business goals. We created the Path to Agility® based on the repeatable patterns we have seen with our clients and organizational change models to describe the activities and outcomes of implementing Agile and their impact on culture and business goals. Based on the proven approach, our software application, Path to Agility Navigator, provides a simple and effective way to continuously improve and measure results from agility.

The image above is an example of a transformation roadmap for an organization focused on improving quality. By using a tool like Path to Agility Navigator, you are able to create a clear transformation roadmap based on your desired business outcomes, to assess progress with, ensuring you don’t lose sight of the bigger picture. If you’d like to create your own custom transformation roadmap, contact us.

Your Transformation Plan

Your Agile Transformation plan is a detailed outline of the specific goals, objectives, activities, and timelines for achieving the desired outcomes of the transformation. It serves as a guiding document that helps stakeholders understand the scope, approach, and dependencies of the transformation.

Rolling out Agile in an organization requires careful planning, preparation, and consideration of various factors to ensure a successful transition. Here are some key factors to consider:

Organizational Culture: Identify cultural barriers and resistance to change that may hinder Agile adoption. Develop strategies to address these challenges and cultivate a culture that supports Agile principles and practices.
Timing: Consider the timing of your Agile Transformation in relation to other organizational initiatives, project deadlines, and market opportunities. Evaluate the organization’s capacity for change and readiness for Agile adoption. Is the timing right for the organization to embark on this transformation journey?
Budget: Assess the budget required to support the Agile Transformation initiative. This includes funding for training, coaching, tooling, infrastructure, and change management activities. Identify opportunities to optimize costs and maximize value delivery through Agile practices, such as reducing waste, improving efficiency, and enhancing customer satisfaction.
Scope: Determine which teams, departments, or projects will be included in the initial scope of the transformation. Consider factors such as business priorities, strategic objectives, and organizational readiness.Balance the desire for comprehensive Agile adoption with the need for manageable scope to ensure successful execution and implementation.
Investment: Consider the investment required to support Agile Transformation in terms of time, effort, and resources.
Buy-in: Secure buy-in and support from stakeholders at all levels of the organization. Communicate the benefits and value proposition of the Agile Transformation to stakeholders, addressing their concerns and resistance to change.

By carefully considering these factors, organizations can determine how to best roll out Agile.

If you’d like to dive into some of the ways to start, we’ve created an infographic of the 9 ways organizations of all sizes implement Agile to help you make the right decision.

No matter which option you choose, management will take on a new role during the Transformation. Instead of traditional top-down management, the leaders in your organization will now learn how to:

Inspire with Purpose
Create Focus
Empower the Team
Enable Decision Agility

With these new skills and an action plan tailored to the unique factors of your organization, leadership will guide the organization through the transition from traditional methodologies to Agile ways of working. Learn how we can help!

Agile Transformation Metrics

Choosing the right Agile Transformation metrics is crucial for effectively measuring progress, identifying areas for improvement, and demonstrating the value of Agile practices to stakeholders. Here are some best practices for selecting Agile Transformation metrics and what to consider:

Align with Objectives and Vision: Ensure that the selected metrics align with the guiding business outcome and vision of the Agile Transformation.
Focus on Leading Indicators: Prioritize leading indicators that provide early insights into the success of Agile adoption and transformation efforts.
Balance Lagging Indicators: Lagging indicators provide retrospective insights into the effectiveness of Agile transformation efforts and demonstrate the value delivered to stakeholders.
Focus on Continuous Improvement: Choose metrics that support a culture of continuous improvement and learning.
Involve Stakeholders: Involve stakeholders in the selection of Agile Transformation metrics to build buy-in and ownership.
Regularly Review and Adjust: Regularly review and adjust metrics based on changing business needs, lessons learned, and feedback from stakeholders.

Start with a small set of core metrics and iterate over time based on feedback, lessons learned, and evolving business needs. Here are some examples of what to measure if you are focused on improving Predictability, Speed, and Quality.

By tracking the metrics mentioned above, organizations can gain valuable insights into the effectiveness of their transformation, identify opportunities for improvement, and make data-driven decisions to optimize their Agile Transformation journey.

To learn how to track metrics related to other transformation goals, view the full list of business outcomes and their example metrics. When you are ready to get started, we’re here to help! Contact us.

Tools To Make Agile Transformation Easier and More Effective

When selecting tools, consider factors such as the specific needs and requirements of your organization, integration capabilities with existing systems, scalability, ease of use, and vendor support. Involve key stakeholders, such as Agile coaches, Scrum Masters, and development teams, in the tool selection process to ensure alignment with Agile principles and practices.

Here are a few tools to consider for Agile Transformation:

Make work visible
If you work in an office, you can create a physical Kanban board or leverage an online tool for hybrid or fully remote teams. We recommend Jira, Asana, KanbanFlow, or Trello.

Collaborate Virtually
We recommend hybrid or fully-remote teams look into Miro as a way to collaborate on ideas with team members.

Focus on Continuous Improvement
We created Path to Agility Navigator to allow organizations to assess Agile Capabilities at the team, system, and organizational levels. By continuously assessing your progress you will create visibility into the transformation, allowing you to share progress reports and action items with stakeholders.

These are just a few of the tools available to support Agile Transformation initiatives across different aspects of the transformation journey. If you’d like to chat about which tools are best suited for your organization, we’d love to help.

Agility in Action: Southwest Airlines (Agile Transformation Case Study)

We helped Southwest through their third Agile Transformation and second SAFe implementation. They wanted accelerated time-to-market, faster response to changes in the market, and improved end-to-end processes to ensure the right delivery of products

Results: Better, Faster, More Efficient

Built and deployed an application into production in 3 weeks. Prior to the transformation, it would have months to complete.
Saved SWA $5M in the first two months
From team and system agility to organizational agility with the engagement and support of C-suites and groups beyond technology

Read the full case study, here.

View more examples of how agility can save organizations time and Money.

Maximize Your Transformation Efforts

It is important that your organization develops the capabilities needed to scale, sustain, and achieve results. Whether you are just starting an Agile Transformation or are already mid-way through, we are here to help. Learn more about our Agile Transformation and business agility services, or contact us to chat with one of our agility experts.

Blog

Webinar Recording: Boosting Organizational Agility – Tips for Gaining Collective Buy-in

By: Agile Velocity | Jan 21, 2024 | Agile Transformation, Business Agility, Leadership

Blog

6 Key Challenges of Agile Transformation in a Hybrid Environment and 8 Strategies to Overcome Them

By: Andy Cleff | Sep 12, 2023 | Agile Transformation

As the pace of change continues to accelerate, embracing agility – the ability to turn on a dime for a dime – has become a key to ongoing success for many organizations. Agile practices, like Scrum and Kanban, initially developed for software development, are now being embraced across all departments and functional areas including marketing, finance, and human resources. However, when companies launch Agile Transformations in hybrid environments, it can introduce a new set of challenges.

What do we mean by hybrid: Do some teams operate remotely, and some in-house? Are teams globally dispersed across multiple time zones? Is there a mix of permanent staff and contractors? All fit our definition of hybrid. When combined with an Agile Transformation, all require an intricate balance of strategies.

(more…)

Blog

Video: What is Business Transformation and Why Should You Care?

By:

Randy Hale & Resalin Gurka &

| Jun 14, 2023 | Agile Transformation, Business Agility, Business Transformation, Leadership

There’s a lot of chatter about transformation….possibly because the entire world just got through (still going through, processing, reeling from?) a pandemic. We saw first-hand just how important agility is when reacting to massive disruption. However, an organization’s ability to be nimble is just as important when the landscape is steady.

One way for organizations to prepare for the next disruption, whether caused by competition, new technologies, or global dynamics, is to build the internal capabilities necessary for pivoting, persevering, and harnessing change to their advantage.

Enter Business Transformation.

But what is Business Transformation and how does it relate to, and differ from, other transformations like digital, product, and Agile?

I sat down with Enterprise Transformation Coaches Randy Hale and Richard Dolman to discuss the benefits of Business Transformation, why it’s worth consideration despite the investment, and how you can get started.

(more…)

Blog

Webinar Recording: Ensure Your Entire Organization is Delivering on the Right Things at the Right Time with Lean Portfolio Management

By: Agile Velocity | Apr 04, 2023 | Agile Transformation, Business Agility, Leadership, Lean, Strategy, Webinar

Companies needing to compete and win with less time, fewer resources, and more pressure to deliver can find massive benefits by implementing and running a lean portfolio. Organizations are often overloaded with competing priorities and more demand than capacity, so how do you decide what to focus on, when?

During this webinar Agile Transformation Coaches David Gipp and Colleen Johnson discussed:

Signs that your organization could benefit from LPM (Lean Portfolio Management)
Why shifting to a value-oriented, outcomes focus matters
The jobs to be done to set up a healthy LPM Function
Success measurements to track progress along the way
How to start the conversation in your organization

Blog

The Top 5 Reasons Teams Regress and Tips to Avoid Them

By: David Pointer | Mar 08, 2023 | Agile Transformation, Leadership, Team

As an Agile Transformation Coach, I have seen my share of successful Agile teams. I have also seen teams plateau at some point struggling to move beyond the initial stages of transformation. A trend I would like to focus on is team regression, which is when an Agile team starts their journey, but along the way may slide back into old habits and processes.

This trend is not abnormal and is dependent on the environment an individual team finds itself in. Most expect Agile teams to be self-sufficient or well established. But, without the focus on improvement or the support to progress, teams tend to slip back to old ways of working, even if they are detrimental to the team’s health. Let’s talk about the top reasons a team may regress.

Reason #1: Lack of Leadership Support

One of the most common reasons an Agile team may regress is a lack of support from direct or indirect leadership. Teams truly desire autonomy and control over how they work, but this desire may not align with how leadership expects teams to behave. Many times, this is because of the lack of synergy between teams changing, while the rest of the organization maintains the status quo. There could be misalignment between leadership expectations vs what the team is actually doing, so the pressure begins to be applied to circumvent the team’s new way of working. Because of this pressure, teams can start to shift back to the old ways of working. Leadership may not see the benefits of Agile or do not want to change themselves to meet the needs of what the team is trying to accomplish.

Reason #2: Conflicting Workplace Culture

Along with leadership, culture can have a big impact on the success of an Agile team. Typically, I see pockets of Agile champions who are challenging the status quo, making ways for new practices, but also some still stuck in old ways resisting the transformation. This conflict between new and old ways of working is challenging for teams on the ground to maneuver through. The organization’s response may be slow, uncertain, and unexpected at times as the initial stages of any transformation are chaotic.

The culture of an organization can also influence how psychologically safe a team feels in changing their way of working. If an organization does not promote psychological safety as part of the culture, individuals and teams will not feel comfortable challenging the status quo and the likelihood of an Agile team thriving or even surviving is greatly impacted.

Reason #3: Unclear Organizational Goals

The focus of an organization can also influence how successful an Agile team becomes. The main goal of any organization is to please and delight their customers. For many, that means a focus on delivery, which can translate to chasing a timeline, which in many cases are not realistic or inclusive of opinions of people on the ground developing and testing. Spending time on innovation and learning may not support that delivery-focused mindset. Teams without a clear goal to work towards will often revert back to old ways of working when things get tough.

Reason #4: Inadequate Staffing of Roles

Another aspect which can cause teams to regress is not having experienced, empowered roles on the team. If an organization does not put effort into hiring or training quality Scrum Masters and Product Owners, the team can suffer. When an organization starts their Agile journey, they may not fully understand the roles needed for a successful Agile team. The organization may experiment with filling these roles before fully committing to adding these roles permanently. The organization may also utilize existing employees to fill these roles or have an employee wear multiple hats of responsibilities. These employees may not have the skillset or aptitude to perform these roles which can slow the ability of the team to mature.

Reason #5: Inability to Make Decisions

In many organizations, decisions are made in a vacuum without clearly communicating those decisions to all affected. Teams on the ground floor don’t know the reason behind the decision, the desired outcomes, or their role in supporting the decision. This leads to teams feeling like cogs in the machine, which reduces employee morale, and the desire to be innovative and think outside the box. By centralizing decision-making, an organization can reduce their ability to get products and services to market quickly. By decentralizing decision-making powers down to the people who know most about the work, more can be accomplished with quicker delivery.

How to Avoid These Traps and Build Successful Agile Teams

Organizations can avoid many of these pitfalls by being intentional about how they start their Agile journey. This would include understanding the outcomes it is trying to achieve, being transparent about what is trying to be accomplished, and communicating this information out to all affected. Organizations need to be more intentional about how they start their Agile journey, starting with:

Right sizing the team
The right roles and skills in each function
Empower the team to make decentralized decisions
Ensuring there is enough leadership support to sustain the strong foundations of an Agile team
Break down organizational silos
Communicate, communicate, communicate

The more intentional an organization is about how they start their Agile journey the higher the chances of success.

If you’d like to improve your organization’s ability to create successful Agile teams and operate with true agility, I’d love to chat. Learn about our team agility service, here.

Blog

How The Formation of Stable Teams Will Benefit Your Entire Organization

By: Kim Antelo | Feb 09, 2023 | Agile Transformation, Team

In our last post about stable teams, Agile Transformation Coach, Kim Antelo, shared why stable teams are important and what you do if you have experts that cannot be on every team. In this follow-up video, Antelo explains how the formation of stable teams creates psychological safety on the team, increases team predictability, allows stakeholders to forecast more accurately, and results in less employee turnover.

If you have any questions on how to form more stable, t-shaped teams, we’d love to help. Learn about our team accelerator service, here.

Read the full transcription below. (more…)

Blog

What’s the Secret to Maximizing the Value out of Agile PI Planning–Whether You’re In Person or Online

By: David Gipp | Oct 19, 2022 | Agile, Agile Transformation, SAFe

The second article of this series talked about success criteria and how to facilitate the voting process. This time, we talk about a critical aspect of PI Planning. Whether onsite or online, how do you make this event valuable and fun.

We’ve talked about how the social aspect of PI Planning is really important and why it makes PI Planning magical. Are there other reasons why onsite PI Planning is your preferred venue versus online?
It’s definitely for the things that happen in the margins. When you are online, you need to precisely plan every interaction. When you are together in a room, you’re going to have unexpected conversations and those are always good surprises.

There are also physical interactions and jokes that inject fun that can only happen organically when you are in person. For example, during one PI Planning, we had a business leader show up in full disguise. He had on sunglasses and a hat so nobody knew who he was. He wandered around for the first 20 minutes but we couldn’t figure it out because it had been a while since we’ve been in person. Once he got up to the front of the room and started sharing his business vision, people were like, “Wow, is that [leader]? Then he took his hat and wig off and everyone figured it out.

The other thing that’s a lot easier in person, is the ability to wander up and listen at the outer edge of any conversation. It’s a lot like an Open Space, you can use the Law of Two Feet and wander over to where you are interested. That cross-pollination of conversation is what yields the best results.

How do you inject fun and create space for cross-pollination online?
In one case, our RTE pre-printed fake event tickets. He did a mail merge so it had everyone’s individual name and assigned them a ticket. The QR code on the fake ticket actually worked! When you scanned the QR code, it took you to the online planning board.

We also had a theme for every one of our PI Planning events, whether it was remote or not. The first one was remote and we went to Hawaii. The second one, also remote, we went to Tahiti. The third one was onsite and we went to Florida (as a theme). The music matched the location: Hawaii was Hawaiian, Tahiti was Polynesian, and Florida was Miami Vice sort of music.

In order to create space for cross-pollination, people will need to be able to move around. For online, we had separate breakout rooms where people could self-select into the conversation they wanted to be in. Prior to the event, you should think about whether you’re going to intentionally send people to breakout rooms or if you are going to allow them to self-select. In the instance of PI Planning, I believe self-selecting works best; people need to be able to choose when they drop in or leave a conversation.

There will be times when you need to gather everyone together in one room, such as when it’s time to listen to the plans or when we’re going to do the confidence vote. I suggest having a main room for that.

Another good idea we use to successfully encourage people to bounce around from room to room is setting up a lobby for lost and found. When someone is thinking “I don’t know where to go” they can go to lost and found and the person staffing that room will tell them where they should be.

I think the biggest reminder about facilitating a remote event is that you have to prod people for that cross-pollination. If you’re physically in a big room, it’s easy to walk over or ask someone to weigh in. But when you are remote, you have to remind people to drop into breakout rooms and encourage them to contribute to the conversation. There’s a lot of lurking that can go on but you should not be shy. Raise your hand, turn on your camera, come off mute, and say “I’m here because I have a question. Can I interrupt you guys?”

Do you have any advice for people who are more introverted? How do you make a more inclusive, welcoming space?
Fun helps with that. The RTE’s and the coaches’ job will be to create a light, safe environment where anything can be said. Scrum masters are a good conduit to those conversations. During the event, we’ll bring all the Scrum Masters together three or four times throughout the day to discuss how much people are cross-pollinating and if we need to keep an eye on [issues]. If there’s a team that needs some help, a coach may decide to join the Scrum Master. Sometimes we’ll create a third ad hoc grouping if we need to get to two rooms together.

If you’re in person, it is easy to tell whether the event is going right or wrong. If the teams are on two different sides of the room and you don’t see people going back and forth, something is not right. It’s much harder when you’re remote to know if things are going well. You need to go out of your way to drop in the breakout rooms and listen. If it’s dead silent, after joining a room for five minutes, it’s probably not going well.

What supplies do you need for in-person?
You need tons of stickies, dozens and dozens of stickies for each team. You need a big chart or foam core board for each team to visualize their plan on. At the front of the room, you’ll need a large program dependency board where we plan who needs what when. You’ll also need red string and scissors to map those dependencies.

You can also use props to increase excitement about the theme of the event. Go to the dollar store and grab sunglasses, confetti, or some sort of table swag that will lighten the mood. This is not conference room planning. It should be fun!

If it’s a train of any size at all, you’re likely going to need audio and visual support. You’ll need projectors and mics so everyone in the room can see and hear what is going on. You’ll also likely need to help people get used to being on the mic. I always have to remind people that if you can’t see the mic in your hand, then we can’t hear you.

What do you say to organizations that may prefer the online version because it’s cheaper and easier to coordinate all of those people?
Well, [online] is always going to be cheaper. The question is, are you getting the same value for the 2-day investment? You’re still taking people away from whatever they’re doing for those two days because we need their full attention even online.

[My opinion] is the cost of food, room, and travel for anyone who’s flying is probably worth the investment given the increased value that you’re going to receive from being in-person. Although we’ve gotten good at [remote] PI Planning, and we’ve been kind of forced to do it, I’m not sure I agree that we’re getting the exact same value [when compared to onsite].

Some companies have a work-from-anywhere policy, but they also have this idea of “Moments that matter.” PI Planning is one of those moments where most companies, even if they have a remote policy, have seen the value in coming together on location for planning.

If there are people that couldn’t attend in person, would you try to incorporate them in a hybrid way?
You can review and discuss on a case-by-case basis. If someone really can’t get there or if they have health concerns, we will adapt and figure out a way to make it work.

[Hybrid] is tough. The level of toughness depends on whether the person needs to contribute or not. We had some people that were remote that needed to see the leadership decks and the output of the event–passive consumers of the plan–and that works fine. The hard part is when you need to contribute in a hybrid environment.

During the last hybrid PI Planning event I was a part of, a few team members that were remote, were on the laptop Zooming with the rest of their team. It was hard to hear though…. In the middle of the event, we actually ran out and got some Bluetooth speakers that we wired to each team so they could hear their remote members and vice versa.

Any last words of wisdom?
It was awesome being back in person. I would always choose to do PI Planning in person if you have the means. It may turn into alternating between remote and in-person. If you can, you should always do [in-person]. I would fear to lose in-person PI Planning completely because they are so effective at reaching the intended outcomes.

Read the whole series:

If you’d like to learn more about how our SAFe services like facilitating PI Planning drive to outcomes, click here.

What’s Your Organizational Agility Score?

In less than an hour, you’ll get valuable insights into your organization so you can improve team performance and achieve your business goals faster.

Blog

Are Stable Agile Teams Really That Important?

By: Kim Antelo | Oct 12, 2022 | Agile Transformation, ScrumMaster, Team

I was recently on a call with executives and the Chief People Officer asked how important stable teams are when looking for a more Agile way of working. Of course, my coach answer is “it depends” but for the most part, they are pretty important.

What are the benefits of stable teams?

Stable teams help to build trust between each other, which allows them to be more likely to pair or learn from each other. Pairing, swarming, and learning from e ach other means that they will be more likely to have less bottlenecks and will be able to improve quality. We also usually see happiness and output go up as a result of stable teams.

What are some of the side effects of not having stable teams?
For each of the things I just answered, you could say the opposite. But at another level, a lack of stable teams impacts our understanding of capacity- the volatility in the team make up impacts the volatility in the amount of work getting done. Not knowing how much work we can complete causes a whole host of other problems for product leaders trying to prioritize and forecast when they think things will get gone.

When might you not be able to have a stable team?
If you need a HIGHLY skilled person who has very specific training with very little time, think PhDs or surgeons. In most technology spaces and business contexts, people can lean in and help each other but if you need a doctor, they can get expensive to put on each team. So instead, you create a team of doctors, have a prioritized list of things for them to work on, and they work closely with the teams they are supporting. Oftentimes in IT we lump in Architects or DBAs with these highly specialized skills. I think those skills are very important but most developers know something about databases and can write SQL. Similarly, Architects can help lead Communities of Practices to create standards and teach aspiring developers about what they do and how they solve problems.

What are some other ways to get around this?
If you cannot create a dedicated team on a consistent basis, what can you do to carve out “Get Stuff Done” sessions (GSD)? Can the whole team focus on team priorities one day a week or a 4-hour block? You can run mini Scrums and have multiple Daily Scrums throughout the session to see if they are on track to get something to done.

I have actually used this pattern often with Agile Leadership teams that are responsible for an Agile Transformation. They typically have other jobs but bringing them together for a 4-hour GSD session helps to move the needle.

Blog

How to Facilitate a Successful PI Planning Agenda

By: David Gipp | Oct 07, 2022 | Agile Transformation, SAFe

In the last article, we talked about why PI Planning is so “magical” and how to prepare (there’s an art) for PI Planning. We continue the conversation with Enterprise Transformation Coach David Gipp and dive into the PI Planning agenda, how it’s similar to other Agile events, facilitating for the best outcomes, and if SAFe is flexible enough to accommodate a request that comes in the night before the event.

How much do you refine and plan during PI Planning?
We always want to plan enough to know that the work will fit in the PI, but we do not need to discover each individual story, even coming out of the PI planning event. We will discover approximately 50% or more of the work, in story form. In the near-term iterations, we’ll know exactly what we’re doing. The farther-out iterations might only have a few things in them, and the very last one may have nothing in it because we know that we’re going to discover new things along the way. There is a ratio between the work we want to know going into it versus leaving some room.

Is PI Planning like Sprint Planning on steroids?
In some ways, you can think of it like that. Let’s talk about the ways it is similar and then we’ll talk about the ways that it’s not.

In the ways that it’s similar, you’re still making a commitment over a time box. In a sprint, you’re making the commitment to complete certain stories within a sprint. In PI Planning, you’re making a commitment (more later about voting on it) to what features and objectives you can commit to during that PI and which ones you cannot.

What’s a little bit different about PI Planning is that we’re still maintaining flexibility on how we’ll get to those features. A lot of things can happen in a quarter. As planning progresses, you can discover some interesting things that can completely change your idea of what features are going to be talked about that day.

As a coach, have you seen that happen?
I’m sure every coach has seen this. It can be very common that once you get everyone talking together you’ll occasionally have surprises. That might mean that a feature you initially think can accomplish is not doable by a certain milestone or release. The ability to accommodate change is built into the system. PI Planning is two days for a reason.

On the first day, we’re doing divergent thinking, we’re examining the solution and we may need to change our thoughts. If we end day one with some unmet expectations, we can use day two to recover and adjust our plan. We may intentionally decide to deprioritize something in favor of another. We may also decide that now is not the right PI to do a particular thing because of the risks that we uncovered, or have a very fast-moving item that needs to jump up in priority. This happened to us in the last PI, we had a legal-related feature request come in the first day of the event so we adjusted the PI plan to accommodate it. That is the beauty of the event being two days. If you only do one day, you’re not going to get the value of being able to adjust your plan.

Two days sounds like a long time and also not a very long time at all, especially when you’re trying to account for the fact that there could be hundreds of people in one room with possibly competing priorities. How do you facilitate? Do you have any tips or advice?
It is a big time investment to bring that many people together in a room. Sometimes we’ll hear leaders say, “why would I bring 90 developers into a room for two days?” To answer that question, I like to point out that the developers are still doing something for those two days. Is their time better used sitting in a cubicle not talking to each other? Or is their time better used talking to each other?

It’s the amount of conversation that happens in those two days that make the investment 100% useful. Those conversations would take weeks or months to happen if they were to have them individually. So that’s what we’re doing, we’re actually saving money by having all those conversations together and we’re not we’re not spending anymore, because it’s two days wherever you sit.

There are some very clear results that we’re looking for and the schedule for the two days is designed to drive maximum value. It’s way more than just getting in a room and talking for two days. It’s the RTE’s (Release Train Engineer) job to maintain that schedule.

So the RTE is the emcee??
Yes the RTE is definitely the emcee, the conductor of the train. It’s very common, especially on a new train, for coaches to help emcee. At some point, the coach will move to the back of the room and hand off the leadership.

Is there any room for a third day?
I’ve seen it go to a third day, but only unusually large groups or dynamic pivots (Covid Pivot is a good example) would cause that need. It’s actually preferable to push through and get to a plan that passes the vote. Just letting the event end with major unsolved problems will always catch up to you.

How do you know PI Planning was successful? What are you looking for?
We’re looking for confirmation that the teams can commit to doing a certain number of features. We want at least a rough plan of what features will be accomplished iteration over iteration .

We care less about the number of stories; that’s not a health metric coming out of PI planning. One success criteria we’re looking to get out of the event is for each team to understand the feature(s) and how they will be contributing (the team objective).

So in the process of communicating objectives, there might be concerns. We might hear, “I’m not sure if we can make that we’ve got a risk of some sort.” We’re looking for risks to be exposed. If we come out of PI Planning with no risks, then we haven’t done enough talking.

So to know if the PI planning was successful, we should have team objectives, identified any risks, and have created a dependency map, also known as the program board.

What does the program board show?
[The board shows] when everyone needs each other*. We need that in order to do releases, so coming out of the PI Planning, we’ll know exactly what the releases will look like and all releases will be confirmed for the program increment we’re talking about.

By confirmed, do you mean they’ll have dates?
We will, hopefully, know almost to the day, when each release will be ready. If there’s an existing release cadence, we’ll know which one we can fit in. That’s usually by the day. If we’re releasing with more flexibility, we will have chosen a date, or at least a sprint or an iteration to release it. Sometimes you can’t choose the release date due to an immovable timeline or event. Features required for the Olympics is a good example that I’ve actually had to work with. The teams in that case needed to scope their work to a date vs pick a date.

But sometimes you can choose between multiple release options, and you make that decision during PI Planning.

Sounds scary.
Well, that brings us to the vote. The most important outcome of PI Planning is that we’ve reviewed our plan and everyone agrees on the plan. During PI Planning, every team shares their team objective and how they will contribute to the features and their team objectives. However, teams do not share the details of every story. In fact, if someone is beginning to explain their plan, and they’re talking [about every sprint], we usually stop them. [We ask] the teams to give us the elevator pitch: What are you contributing to the features? How will that work be done? What are the risks?

The elevator pitch should be given in non-technical language. There can be some technical language but everyone in the room should be able to understand each team’s plan.

Now, that brings us to a very, very interesting component of PI Planning, the vote. Some people wonder who’s voting… It must be the teams just voting on their plan, right? No, everyone who has heard the plan, votes. It makes for a very interesting form of peer review.

So each team will stand up and say: “This is Team Rocket Ship. We’re going to be contributing to this feature by x and here are the risks.” Then people vote?
We hear all the plans in sequence so we can build a complete picture. If you plan your pitches and readouts correctly, a very nice story develops.

So, each team is a car on the train, each car goes in sequence, and by the end, you should have objectives from the first car to the caboose?
Yep. Anyone that’s heard [all of the objectives] gets to vote on the validity of what they heard. Some people think that teams are just voting on their part of the plan but by the time they’re explaining their plan, they should already believe in it. You don’t present a plan that you don’t believe in. The real question is, do you believe in the plans of other teams?

This exposes some very interesting moments. I’ve heard teams out of concern say, “No…I’m worried about you guys. You said you could complete those features but you have all the work planned until the end of the PI and I can’t confidently vote that I think you’ll be able to accomplish that without personal sacrifices like long nights. I’m worried about you.”

From an empathy and culture standpoint, that’s an awesome conversation to have.

When does the vote happen?
Everyone hears the plan and then we take a small breather. I’ll usually ask for everyone to stand and pass out some mics. Then on the count of three, everyone holds up their fist to five.

We’re looking for threes and above. We will pass the mic to the twos and the ones to hear from the people that are low. The best way to facilitate this is to not have a coach talk to a one or a two, but to have a five talk to a two. Sometimes, the conversation between a low score and a high score solves it. “Oh, you’re so confident because we have the new library. I’m confident now too.” If we have any sticking points, we take those as leadership actions and might have a quick pause to see if we can solve them immediately. If we can’t solve them, we might have some more reprioritization to do. Most of the time, we can come up with a way to become confident in the plan.

Does every vote count equally?
We want to promote that every vote is equal and support anyone who’s willing to vote a two or a one. Those are the people that I will go stand right next to so that they don’t feel alone. I’m never comfortable when you’re having a confidence vote that is all fours and fives and you escape without discussion. That’s not the point. You need to be sure that you’ve examined [the plan] and that means someone’s got to play that person. We make [the environment] safe going into the vote. If you really want to vote a two or three, we’re looking for you to help expose risks.

*A program board shows dependencies between the work and people. There’s a lane for each team, and the board show major dependencies along the way needed to deliver each feature.

In the next and last article of the series, we’ll talk online vs onsite PI Planning, the importance of fun, and share examples of how an airline took their PI Planning events to the next level.

Read the whole series:

If you’d like to learn more about how our SAFe services like facilitating PI Planning drive to outcomes, click here.