Topic: PI Planning

PI Planning—Plan to Discover the Next PI – Improving SAFe Journey

Posted on

Note: This is the third post in the Practice Makes Permanent series. Read the first post here and the second post here. You can watch my webinar on PI Planning here.

Is your SAFe® implementation slowing? Has the energy and enthusiasm faded and it feels like just one more process change? Maybe you’re just not seeing the value you expected? That’s OK because PI Planning presents significant opportunities for your relentless improvement of the SAFe journey.

If you’ve read the previous posts in this series, you know that the right kind of SAFe practice doesn’t make perfect, it makes permanent. And you know that using creative tension will help you find the right outlook to discover new opportunities and foster relentless improvement. The reality is that many Agile Release Trains (ARTs) have a distorted view of PI Planning—they see it as a readout of the already created plan or a time to direct teams toward a plan rather than the discovery session it’s intended to be. This makes it a great place to get your implementation back on track. PI Planning is an opportunity to discover the plan for the next PI. Discovery is exciting, it’s engaging, and it’s about learning.

Through my years of teaching and implementing SAFe, I’ve identified key practices to help organizations successfully discover a plan for the upcoming PI. My goal in providing these tips and techniques is to give you practical ideas on how to revolutionize your PI Planning and improve the quality of your plans.

Consider these key practices to make PI Planning a discovery session:

  • Breadth vs. depth planning
  • Good objectives start early
  • Iteration plans from PI Planning are “what if?” scenarios
  • Raise the levels evenly
  • Preconceived is pre-committed—limit pre-PI Planning

Breadth vs. Depth Planning

During PI Planning, the Agile teams are instrumental in converting the ART vision and roadmap into team-committed objectives while discovering the risks, dependencies, and delivery goals for the PI.

The anti-pattern

A very common anti-pattern in PI Planning is when teams focus on one iteration at a time, attempting to create a solid plan for iteration one, followed by a deep dive in iteration two, and so on. This is dangerous because we’re not seeing the big picture of the whole PI. And often we get to the draft plan review, and the teams don’t have a high-level, end-to-end plan, which is critical for the management (adjustment) review and problem-solving activity.

Additionally, because teams have gone iteration by iteration, concentrating on creating and loading stories, they haven’t collaborated sufficiently on with other teams on dependencies. This can potentially lead to radical plan changes during team breakouts on day two.

Implement breadth vs. depth

This is where breadth vs depth comes in. Encourage your teams to think across the whole PI and create a very high-level plan within the first 60–90 minutes of the first breakout session. This will include initial starter objectives, the discovery of some initial dependencies on other teams, high-level goals for each iteration, and some initial stories (perhaps slotted into an iteration). These activities give teams a broad, overall approach.

Now, they can use the remaining time in the breakout to improve the depth by:

  • Discovering more stories
  • Identifying more dependencies
  • Refining objectives
  • Identifying and (perhaps) mitigating more risks

This breadth vs. depth strategy ensures that there’s always a draft plan to review and helps teams align on the approach and effort distribution.

Here’s a quick recap of the key principles of breadth vs. depth:

  • Start with a high-level, end-to-end plan that’s full of holes.
  • As time permits, go back and fill in those gaps.
  • Focus on “based on what we currently know, this is our plan. However, we know we have more to learn to fill in some gaps.”
  • Raise the water level evenly. Create some story placeholders, which will generate some objectives, which will raise some dependencies, which will identify more stories, which will update objectives, and so on.

Apply SAFe® Principle #3: Assume variability; preserve options. Start with minimal constraints and a high-level approach and add details as they emerge.

Good Objectives Start Early

Team objectives are one of the key outputs of the planning effort. Objectives are a team’s opportunity to say:

“Hey, ART leadership, we saw the vision, we saw the roadmap from the top x features. Here’s our contribution to the success of the ART for this PI.”

This is a powerful opportunity to engage SAFe Principle #8 and SAFe Principle #9 and is a critical component to ensuring alignment.

Many teams struggle with understanding objectives because they’re not used to being asked, “What can you contribute to our success?” Instead, they’re used to being told “this is what needs to be done.” I like to explain objectives with an analogy.

Team objectives

Imagine you’ve just read a really powerful, thought-changing book (such as Donald Reinertsen’s Principles of Product Development Flow). Most likely you’ve read the book chapter by chapter. You want to share the power of that book with your friend, and you’ll probably share highlights and key areas and concepts from your perspective. Now, another friend reads the same book and shares their key takeaways from their perspective. While there may be similarities in key concepts (for example, Economic Sequencing) each perspective may pick up on different areas and ideas that were key to them but that maybe didn’t stand out to you.

The chapters in the book are the features. All the teams read the features and come away with their key areas and contributions. These are the team objectives. Some teams may have shared contributions across the ART (Program Objectives), but many will have specific contributions unique to their own team (Team Objectives).

Start early, iterate often

So, how do you achieve these powerful objectives within PI Planning? That’s where the phrase “good objectives start early” comes in. Objectives should start as early thoughts and concepts and grow in clarity and alignment as the breakout continues.

These are the key principles to successfully writing objectives:

  • Start writing objectives early in the first breakout.
  • Don’t wait until you have ‘perfect’ objectives; perfect is the enemy of good.
  • As you learn more about the plan during the breakout conversations, potential objectives will emerge. Write these down, no matter how incomplete they are.
  • As you learn more about the objective through further planning-fueled learning, update the objectives.
  • Don’t try to start with SMART objectives, work toward them.

Iteration Plans from PI Planning Are What-If Scenarios

A common issue that limits the self-organization aspect of SAFe Agile teams is the mistaken belief that teams are creating iteration plans that must be locked in and committed to. This is a highly critical point: teams do not commit to iteration plans in PI Planning. They’re committing to the objectives they discover, and to the Program Board, which identifies when they believe they can deliver on the features and what dependencies are needed to deliver. When teams have the false belief that they’re going to be held accountable for plans for four iterations in sequence, they become nervous, realizing they can’t really know exactly what will be needed for each iteration. They believe they’re being held to a mini-waterfall approach. Actually, the opposite is true.

We ask teams to create iteration plans so that they can discover the objectives they want to commit to, discover the significant dependencies needed to deliver the features they pull in and discover the risks that may threaten the plan. The plan they create is one of many possible ways they can deliver, and many of the details of the actual plan will surface as they execute that plan. In my experience, the specific iteration plans the teams create are about 60-percent accurate. As long as we have the significant dependencies and risks identified, that level of accuracy is good enough to get started.

Key principles around the what-if scenario approach:

  • Teams do not commit to iteration plans. They commit to objectives and the Program Board’s dependencies and Feature deliveries.
  • Teams create iteration plans to unearth dependencies, discover objectives, and learn how to deliver to the business.
  • The iteration plans will almost certainly change as we iterate through the Program Increment. Understanding that we are only identifying one of many possible scenarios to deliver on these objectives helps the teams focus on what’s important.

Raise the Levels Evenly

Closely associated with the breadth vs. depth concept is ensuring you have a good balance of focus on each component of the Draft Plan Review. Following SAFe Principle #4, we want to shorten our Plan-Do-Check-Adjust (PDCA) cycles to increase the pace of learning. If you think of each key area of focus in the team breakout, we have:

  • Creating, sizing, prioritizing user stories and enabler stories
  • Identifying and improving team objectives
  • Identifying and attempting to mitigate risks
  • Discovering, discussing, and gaining commitment to cross-team dependencies
  • Updating the Program Board as we discover new feature delivery and dependency aspects in the emerging plan

Consider each of these areas as buckets to fill. We don’t want to fill one bucket to the top and then go to the next. Instead, we want to evenly bring up the level on all buckets together. That means we want the teams to generate some stories, which can lead to updated objectives, which can lead to new risks identified or mitigated, leading to new commitments with other teams, and leading to updates to the Program Board. This order is not rigid, there’s nothing wrong with discovering a dependency, adding some stories to cover this dependency, and then updating Program Board. The idea is to make sure that we are keeping the levels (amount of recorded information) approximately even across all the buckets.

safe for business

These are the key principles to raising the levels evenly:

  • Don’t try to create a full iteration-by-iteration plan too early.
  • Use the energy and knowledge from adding to one bucket to add to the next bucket.
  • At regular intervals, step back and review the levels in each bucket. Are these relatively evenly filled? If not, do we need to revert to focus on a particular bucket?
  • At key points, review the entire plan we have created so far. Do we see major gaps? Dangerous assumptions? Note: a great time to do this is about five minutes before the next Scrum of Scrums team breakout. It provides a really clear view of the current progress that will help us identify any systemic issues in our planning process.

Preconceived Is Precommitted—Limit Pre-PI Planning

Before we start PI Planning, we need the right level of readiness. But too much can lose the discovery aspect of PI Planning. Finding that balance is a learning journey, but there are key elements to balance.

Too much pre-PI Planning:

  • Takes away from the current PI effort. The focus should be on this PI’s objectives, not pre-planning for the next.
  • Locks into a plan that is not well-informed. PI Planning is about learning, not perfecting. The best objectives come from shared learning during PI Planning.
  • Damages the team-of-teams culture in the ART.

Too little pre-PI Planning:

  • Leaves the teams anxious
  • Can waste time in PI Planning trying to answer foundational questions

The right balance of PI Planning:

  • Allows teams to ask intelligent questions during the morning briefings. The test I apply is to verify: are the questions probing and refining (good) or are they high level and more about initial alignment (not so good).
  • Ensures we have the right people in the room. For this PI’s features, we may need other shared services and assistance. Knowing this in advance helps us extend invites to the right people.
  • Sets the stage for PDCA-based learning cycles during PI Planning. When teams come into PI Planning thinking they already have the right plan, it leads to a fixed mindset for the next PI, which blocks the true discovery needed. We want the team of teams (ART) to iterate through these PDCA cycles together as they discover the plan.

I use a very simple approach—called the five-sticky rule—to help teams understand a good starting point for the level of pre-planning needed. Each team is encouraged to bring five sticky notes into PI Planning that represent potential stories. This requires the team to do enough discovery around the features, vision, and other elements needed in the next PI but keeps them from creating a deep-dive plan that loses the discovery aspect. Please note that the five-sticky rule is more of a guideline than a rule and can be adjusted as needed.

These are the key principles to finding a balance of pre-planning:

  • Prepare to create the plan, don’t pre-create the plan
  • Look for intelligent, informed questions during the briefings
  • Beware of a fixed mindset view of the plan coming into PI Planning

PI Planning is one of the Ten Critical Success Factors to achieve transformational progress with SAFe. By applying the above ideas, you can make it the dynamic, engaging, energetic event it’s intended to be. So, go make your PI Planning a discovery session!

Check back soon for the next post in the series.

About Dwayne Stroman

Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer

Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.

Practical Tips for the New RTE – Business Agility

Safe Business Agility

Release Train Engineers (RTEs) play an important role in aligning the organization and maintaining it during PI Planning. In this episode, we talk to Kimberly Lejonö and Carl Starendal, both former RTEs and experienced Agile coaches, who share their tips for RTEs just getting started in their role. And we’ll dive into some questions we hear from RTEs in the field around inspiring change across teams and Agile Release Trains (ARTs) and managing the flow of value.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Subscribe

Share:

Release Train Engineers (RTEs) play an important role in aligning the organization. In this episode, we talk to Kimberly Lejonö and Carl Starendal, both former RTEs and experienced Agile coaches, who share their tips for RTEs just getting started in their role. We’ll also dive into some questions we hear from RTEs in the field around inspiring change across teams and Agile Release Trains (ARTs) and managing the flow of value.

 Topics that Kimberly and Carl touch on include:

  • PI Planning preparation and execution
  • Maintaining alignment during the PI
  • Supporting cultural change
  • Metrics, and what not to measure

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Visit Melissa Reeve’s Bio

Guest: Kimberly Lejonö

RTE, project leader, and scrum master

Tapping into her background working as an RTE, project leader, and scrum master, Kimberly brings a high-energy and curious mindset to affect change in others. She loves connecting with the people around her and unlocking their potential to help organizations move in their desired direction. Connect with Kimberly on LinkedIn.

Guest: Carl Starendal

Carl Starendal

With a background in game development and a decade of hands-on experience at the center of global Lean-Agile transformations across multiple industries, Carl co-founded We Are Movement, an Agile and Lean advisory team based in Stockholm. A highly regarded trainer, advisor, and facilitator, he is a passionate advocate and resource for organizations throughout all stages of the Agile journey. Carl is recognized internationally as a speaker on leadership, Agile, and product development. Find Carl on LinkedIn.

Creating Your PI Backlog Content – Agility Planning

Posted on

Glenn Smith and Darren Wilmshurst with Radtac, a Scaled Agile Partner, co-wrote this blog post. 

At the conclusion of Program Increment (PI) Planning, we’re always reminded of something one of our colleagues always says. There’s much to celebrate because we’ve created a set of committed plans. But we first have to complete a retrospective of the PI Planning event (cue groans from everyone in the room) and we “start preparing tomorrow” for the next PI (more groans).

Moreover, the critical path for any PI Planning is the creation of the content, suitably refined and prioritized. Without this, we can’t do any planning! But what does this look like in practice? 

This blog post is aimed at coaches who need to think about the content preparation for the next PI. By that we mean SAFe® Program Consultants (SPCs) supporting the Agile Release Train (ART) and Release Train Engineers (RTEs). But more importantly, Product Management (PM) and System Architects (SA) need to create, refine, prioritize, and socialize the content supported by Product Owners (POs) and Business Owners (BOs). We will explore each of these roles in turn during the course of this post. 

The traditional siloed hierarchy of organizations can engender a ‘this isn’t my job’ attitude. Yet many people and roles need to work together to create a compelling backlog that delivers economic benefits and satisfies your customers.

The visual model below is a high-level view of the intensity of the preparation activity for each of these roles. It isn’t meant to represent the number of hours. That is, high intensity does not mean 100 percent of your time, we just expect more time spent on preparation while recognizing that there will be other things to be done.

PI Backlog Content
Preparation intensity for specific roles.

You will also notice that there is a significant spike in preparation during the Innovation and Planning (IP) Sprint for PM, BOs, POs, and the Teams. This is when PI Planning happens.

Product Management and System Architect

PM and the SA will follow a similar pattern to each other, as their roles are two sides of the same coin—one focused on the outward market and the other technically oriented. They are going to be collaborating and working closely to make sure their respected needs are met and the right balance of the work is correctly scheduled.

Crafting backlog items for an ART, whether they are Business Features or Enabler Features, follow a pattern of Creating, Refining, Prioritising, and Socialising. While overly simplistic, each step could follow the first four iterations of a PI. In the first half of the PI, expect PM and the SA to be looking to the future. This will include looking at upcoming Epics, decomposing existing Epics, and the ART roadmap and associated Architecture Runway.

A common pattern is to see poorly defined Features with weak benefit hypothesis statements and acceptance criteria. It shouldn’t be overlooked how much effort this takes to do well. This is because the work involved isn’t just writing them down in your Agile Lifecycle Management tooling, but working with BOs, talking to a wider stakeholder cohort, including customers, and reviewing market trends. Improving their own understanding of the value proposition and scope enables people on the ART to more easily deliver against it. Through the PI, their effort tapers as other cohorts take the backlog content and prepare for PI Planning.

Business Owners

BOs are key stakeholders and critical friends of the ART. As such, they gradually experience an increasing demand on their time to support creating backlog content throughout the PI—with the most involvement happening during PI Planning. As a cohort, BOs are available when needed by the likes of PM, and actively participate in the System Demos every iteration. Here, they not only get to see the progress of delivery but give feedback to help PM and the POs inspect and adapt the backlog.

We recommend that prioritization be a ‘little and often’ affair. And as it is a team sport, BOs must attend these sessions (these are the little spikes on the BO line in the model).

Product Owners

In a scaled environment, POs serve both the team and the train. In the initial periods of the PI, as you might expect, the PO has both a team execution focus and needs to support PM with Feature creation and refinement. As the content starts to get in better shape for the upcoming PI Planning, PO involvement increases, but with a shift in focus to Feature elaboration and decomposition into drafting user stories to later socialize with the team.

The Team

Through most of the PI, the team is execution-focused, although on hand for those ad hoc, short whiteboard sessions with PM, SAs, and POs. Larger demands on the team’s time should be scheduled like any other demand on their time—after all, work is work! This will be done through the use of exploration enablers in a future PI, or spikes and innovation activities that occur during the IP iteration. Either way, the outcome is gaining knowledge that reduces the uncertainty of future work.

The team’s involvement, however, peaks during the IP iteration when the POs socialize the upcoming backlog of work—the Features and the draft stories they have created. It is during the preparation for PI Planning that the team takes time to understand what is needed and answer questions that need “I’ll look in the code” to find out.

Release Train Engineer and Scrum Master

Hey wait, you didn’t forget about the RTE and Scrum Master (SM), did you? Surely they are just facilitators, we hear you say, what do they have to do with backlog items? But let’s think about this. As facilitators at the train or team level, they are key advocates for the improvement of flow and value delivery. Therefore, it is not unreasonable to expect them to create improvement items that require effort from the teams during the PI. And we know that anything that requires effort from the teams should be planned accordingly.

The items that the RTE and SM will bring to the table for inclusion will likely come from team retrospectives, the Inspect and Adapt problem-solving workshop, or from insight gained from activities like the SAFe® DevOps course.

Creating Content During PI Planning

During each PI Planning session, PM presents the vision, which highlights the proposed features of the solution, along with any relevant upcoming Milestones. While some may feel that at this point in the proceedings the content creation is over for PM, there is actually still work to do. During the planning, there will likely be scope negotiations and prioritization calls needed as the teams get deeper into understanding and scheduling in their breakout sessions.

Similarly, the BOs have a role in adaptive content creation too. Beyond providing the business context in the briefings, they will work with the team to discuss the needed outcomes from the work. And they’ll support PM and the SAs in adapting the scope from what was originally crafted—because tradeoffs need to be made during planning. Discussions with the teams during the assignment of Business Value could influence what gets produced in the upcoming PI too.

While the POs and the Teams need to sequence and plan their stories to maximize economic results, there will almost certainly be variability of scope that will need to be accommodated as new information emerges. This will involve further elaboration, negotiation, planning, and reworking of the content during PI Planning.

In addition, the model shouldn’t be followed religiously, but used to identify who, when, and by how much focus the different roles on the train need to spend to make this happen. While putting an emphasis on the quality of the backlog items is going to help your ART, it alone won’t fix your delivery problems but will act as a key enabler in doing so. 

It is important to give a government health warning at this stage: context is king! While we have given our view on the preparation activities and the intensity, your context will provide a different reflection. In fact, when creating this post, we both had a slightly different approach for prioritization based on our respective experiences. Neither is right or wrong but a reflection on the clients that we have worked with. So please treat the model we have created as a ‘mental model’ and something you can use with your trains to frame a discussion. 

The pattern, while broadly accurate, will change in some situations, particularly if you are preparing for a training launch and this is your first PI. Here, the cadence may be condensed and more focused, but this will be guided by the quality of the backlog content you already have.

A final thought and back to our colleague who says that “PI Planning starts tomorrow.” So does PI Execution. There’s no point in making a team committed to the plans that you have created and then not executing on them. Otherwise, what was the point of PI Planning in the first place?

If we’ve piqued your interest, check out this post about changing a feature in the middle of the PI. It’s a question we always get asked when we teach the Implementing SAFe® class.

About Glenn

Glenn Smith is SAFe program Consultant Trainer (SPCT)

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: We’re Giving More Than a Donation for Pride Month

Read the Blog Post

Agile Planning to 100% Capacity? Don’t Do It!

Posted on
Agile team planning

Someone asked me the other day why Agile teams don’t plan to full capacity. Think about this scenario: during the last PI, a team on the ART achieved 50 percent of its planned business value. Stakeholders weren’t pleased with that result. When the team held its retrospective to examine its performance, several issues came to light. High turnover and lots of team members shifting between teams prevented them from finding their groove. People were experiencing burnout from moving too quickly while trying to correct quality issues.

As a scrum master, I coach my teams to plan to less than 100-percent capacity (see scenario above). But I understand why that doesn’t always make sense to stakeholders. They worry that it will result in even fewer met commitments. Teams need a way to talk to stakeholders about how they need to plan less and yet somehow deliver more. It’s easy to criticize the stakeholders. Of course they’re going to ask for more—that’s their job! They may not understand why agile teams estimate and how they plan agility. They don’t see the burden that agile planning to maximum capacity places on the team.

We need to shift the stakeholders’ perspective. So, here are five key things I’ve learned about capacity and predictability that could be persuasive input.

1. Agree on what capacity means

In a recent iteration planning meeting, I asked the team to give me a number that represents our capacity. There was general consensus that we should plan to 80 percent capacity. It didn’t take long to realize that we all had different ideas about what it means to allocate 80 percent of our capacity. Is it 8 points per person? Or 80 percent of 8 points? Doesn’t SAFe® tell us somewhere? 

SAFe doesn’t prescribe a measure. Whether we agree that our team’s capacity is 45 story points or 200 hours, what matters is that the team agrees to some quantitative measure of their capacity for progress. 

2. Balance business needs with team capacity

A little pushing outside our comfort zone is a good thing, and can even be inspirational. Often, it’s uncomfortable to try new things, such as setting goals to do more or work faster than we have before. Yet that discomfort can lead to growth and achievement. Think about athletes getting better by pushing themselves to do things they’ve never done before—run faster, lift heavier, jump higher. As a team, we want to win the championship!

But when we push too much, we experience burnout, high turnover, and a lack of creative problem solving because we’re constantly rushing to meet deadlines. Take the athlete analogy—rest, recovery, and refueling via sleep and nutritious meals are essential to an athlete’s success. Otherwise, they risk injury, burnout, and decreased athletic output. Simply put, we need to help the team find its balance so it can thrive. 

3. Find confidence in your understanding of the work

Agile team planning

Whether your team is developing software, creating marketing strategies, or negotiating a contract, the amount of time required to complete any given task will vary. New teams and ARTs might take more time as they’re forming and storming. Building a new product could take more time during the early development stages because we don’t know how it will be received by customers.

When estimating the size of work, my team uses several perspectives. We assess work based on three criteria: volume, complexity, and our knowledge about the work. We ask ourselves questions like: Have we done this before? How much space do we reserve for the unknowns? Through conversations, we all gain a better understanding of the work. Our certainty in estimating fuels our confidence that we’re pushing ourselves to achieve excellence without the risk of burnout.

4. Protect space for built-in quality and problem solving

I like to keep a monthly budget for personal finance. I know from experience how unwise it is to spend all the cash I earn! I need to be able to respond to life’s unknowns, so I reserve some income for savings. It’s also smart to invest in the future. Early in my career, it was hard to imagine allocating any of my hard-earned salary for investing. (“I’ll start next year!” I’d tell myself.) But every day that went by was a missed opportunity.

The same concepts apply to teams approaching problem solving and innovation. We need “savings” to respond to life’s inevitable unknowns. Innovation can be applied incrementally, like little investments. When the team is constantly rushing to meet an overwhelming list of iteration goals, it’s like living paycheck to paycheck. 

5. Slow down to speed up

As a sailor in the U.S. Navy, I learned the saying, “slow is smooth and smooth is fast.” When we were performing meticulous, potentially dangerous tasks aboard naval ships, time was of the essence, and safety and accuracy were paramount. Go too fast and you risk sloppy performance, decreased accuracy, and an unsafe environment. Conversely, go too slow and you risk the mission. As sailors, we lived by “slow is smooth and smooth is fast” to develop awareness and learn to strike the balance between speed and accuracy.

Agile teams are similar. They need time and space to define and automate their processes and to create the environments and infrastructure to ensure built-in quality.  Slowing down this PI helps accelerate the next, and with higher predictability.

As I was writing this post, I spotted a conversation about capacity happening in the SAFe Agilists forum on the SAFe Community Platform (login required). Forums like these are great places to ask questions, share your knowledge, and learn something new. I hope you’ll check them out the next time you’re looking for advice.

About Sam Ervin

Sam is a certified SAFe® 5.0 Program Consultant (SPC)

Sam is a certified SAFe® 5.0 Program Consultant (SPC) and serves as the scrum master for several teams at Scaled Agile. His recent career highlights include entertaining the crowd as the co-host of the 2019 and 2020 Global SAFe® Summits. A native of Columbia, South Carolina, Sam lives in Denver, CO, where he enjoys CrossFit and Olympic weightlifting.

View all posts by Sam Ervin

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: The Power of Customer Feedback in Prioritizing Work

Read the Blog Post

SAFe® Program Dependency Board Retrospective – PI Planning and Execution

Posted on

Learning from the program dependency board

SAFe® Program Dependency Board Retrospective

The SAFe program board, or program dependency board, is a key artifact used in PI Planning and execution. The Agile Release Train (ART) teams and stakeholders used it to align, anticipate risks, and adapt the plan accordingly.

This inspection and adaptation of the plan based on insights from the program dependency board is first-loop learning—making changes in the plan based on what we see.

Deeper learning from the program dependency board

What we rarely see, though, is deeper learning from what the program dependency board shows us. It’s like the good old times where you would see a project manager/PMO working their Microsoft Project Gantt Chart, moving things around, but rarely stopping to ask deeper questions around the base structure of their plans and why they’re based on a waterfall model.

Program dependency boards can drive deeper learning about the structure of our ART and its alignment with the kind of mission/vision we’re pursuing, and the backlog of features we’re working on. If we see too much red yarn on our boards, it isn’t something to be proud of. Yes, we can be proud that we identified the dependency and even more that we were able to massage our PI plan to deal with it in a reasonable way. But too much red yarn means too many dependencies. Too many dependencies mean our Value Stream network isn’t configured well. It means we should probably look at ways to reconfigure the network (meaning restructure teams and maybe even the ART).

When to do this deeper learning

I get it. This sort of learning is hard to pursue in the heat of PI Planning. And all too often when PI Planning is done and we have a workable plan in hand, it’s tempting to just move into execution. Resist the temptation. Let the dust settle, but find the time that makes sense to have a deeper retrospective that is based on the patterns you see on the program board. This can be a good discussion in your Scrum of Scrums or with an extended forum that includes the wider ART leadership.

SAFe® Program Dependency Board Retrospective

There’s no need to wait for the next inspection and adapt (I&A). It’s fresh now and outcomes from this retrospective might anyhow require a lot of refinement and consideration before they’re actionable. Start the process early in the PI, so hopefully, you’ll be in a position to reconfigure the network going into the next PI as needed.

A typical pattern is when such a retrospective raises the need to rerun a Value Stream identification (VSI) workshop.

Validating the Value Stream design hypothesis—a key but often skipped step

Speaking of the VSI workshop, one key element in it that many practitioners skip is the validation of your Value Stream design hypothesis. After identifying a development Value Stream, run some water through the pipes—take some work in the form of Features or even higher-level Epics/Themes and explore how they will flow through this Value Stream/ART/Solution ART. If the work flows nicely with a minimal number of dependencies, you found a good setup. If even in this ‘dry run’ you already see you have too many dependencies, time to rework the design!

PI Planning dry run

And yes, what this dry run means is that ideally, even in this early phase, before even launching the ART, you should consider doing a light version of PI Planning with the Value Stream design you have in mind to see that it makes sense. You don’t want to train everybody, spend a serious amount of time on preparing to launch the ART, and then find it’s not a self-sufficient ART or that it’s comprised of teams that aren’t self-sufficient.

Summary

I’ve talked about some recommended SAFe best practices here—some are implicitly mentioned in SAFe, and some complement the formal guidance. The key point I wanted to make is how important is it to aim for the right Value Stream network and to continuously inspect and adapt so that value can easily flow with minimal dependencies and slowdowns. And if your Value Stream network is configured well, everything else becomes much easier.

If you’d like to read more about my SAFe experiences in the trenches, I’ve written an e-book. I’ll also be at the upcoming 2020 Global SAFe Summit on the Agile Marketing panel, at the AgileSparks booth in the Partner Marketplace, and at the SAFe Experts Coaching Station. I look forward to connecting with you.

About Yuval Yeret

Yuval Yeret is the head of AgileSparks (a Scaled Agile Partner)

Yuval Yeret is the head of AgileSparks (a Scaled Agile Partner) in the United States where he leads enterprise-level Agile implementations. He’s also the steward of The AgileSparks Way and the firm’s SAFe, Flow/Kanban, and Agile Marketing. Yuval is a SAFe Program Consultant Trainer (SPCT5), a Professional Scrum.org Trainer (PST), an internationally recognized Kanban Trainer, a thought leader, recipient of the Lean/Kanban Brickell Key Award, and a frequent speaker at industry conferences.

View all posts by Yuval Yeret

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: The Power of Informal Learning Networks

Read the Blog Post

Stories from the Field: Patterns in PI Planning and Its Impact – SAFe® Ceremonies

Safe Business Agility Podcast Cover Image

In this ongoing series, our customers and partners share their stories from the field about working with SAFe® ceremonies and SAFe implementations. This episode features Vikas Kapila, SPCT at Enterprise Agility Consulting, who talks to us about the various patterns he’s seen in PI Planning and the impact they’ve had on organizations’ outcomes.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Subscribe

Share:

Visit this link to learn more about PI Planning references in the podcast:

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Visit Melissa Reeve’s Bio

Guest: Vikas Kapila

An SPCT5, since 2015, Vikas is CEO, Curator at Enterprise Agility. He focuses on enabling individuals to transform into a high-performing team and realizing how the sum of the team is greater than the sum of the individuals. With more than 20 years in solutions delivery, consulting, and coaching, Vikas has a proven track record in successfully delivering complex solutions (transformations) to multidisciplinary and multicultural teams. He also excels at fostering partnerships between business and IT, starting with a shared vision to create and deliver solutions that delight customers. Over his career, Vikas has worked with companies such as AIG, Bank of America, Capital One, Mercedes, Walmart, and Unisys among others.

Learn more about Vikas on LinkedIn

Aligning Global Teams Through Agile Program Management: A Case Study – Agile Transformation

Posted on
Agile Program Management

Like many organizations, Planview operates globally, with headquarters in Austin, Texas, and offices in Stockholm and Bangalore. About two years ago, we launched a company-wide initiative to rewire our organization and embrace Agile ways of working—not just in product and R&D, but across every department and team, starting with marketing. We developed three go-to-market (GTM) teams, whose goals and objectives centered around building marketing campaigns to create a pipeline for sales. Each team aligned to a different buyer group, with members from the product, marketing, and sales.

The challenge: integrating international teams in our Agile transformation

Like many organizations, we struggled to align and execute our marketing programs across our international teams, defaulting to “North-America-first efforts” that other regions were then left to replicate. As we built out these new groups, we considered how to best include our five-person team of regionally aligned field and demand marketers in Europe, the Middle East, and Africa (EMEA).

At the beginning of our Agile transformation, the EMEA marketers were often misaligned and disconnected from big-picture plans. The EMEA teams were running different campaigns from those in North America. Before forming cross-functional GTM teams, the EMEA team had to individually meet with the different functions in marketing, product marketing, and other departments. The extra complications of time zones and cultures also made it difficult to get things done and stay on strategy.

With team members feeling disconnected, at Planview we suffered lower-impact campaigns and less-than-ideal demand generation. To succeed in our Agile transformation journey, it was critical to properly align the international team through an integrated Agile program management strategy.

The approach: forming and integrating the EMEA team into Agile program management

While the three GTM teams had dedicated cross-functional members representing demand generation, content strategy, and product marketing, it was clear that assigning an EMEA team member to each of these teams wouldn’t solve the problem. Each EMEA marketer is organized by region and language, not by GTM Agile Release Train (ART), so we needed to develop our own EMEA Agile program that would meet the challenges and achieve the needed international alignment.

Agile Program Management

Working with our Chief Marketing Officer and other stakeholders, we determined that we would continue to align our EMEA team by region/language. Now that the GTM teams were formed (with each team having all the necessary people to deliver end-to-end value), the EMEA team could meet with each team in the context of the prioritized strategic initiatives. Drawing on our local expertise, we could weigh the campaigns from the three GTM teams against each other to determine which would drive the most pipeline and impact in each region. This structure enabled EMEA marketers to opt into GTM campaigns that were regionally impactful, instead of creating standalone campaigns. This approach has been a success. At our last PI planning event, EMEA progressed from just replicating campaigns into co-planning and co-creating the campaigns that were of local interest and fit.

By including the distributed teams in Agile program management, we achieved better alignment as a global marketing team; gave our EMEA marketers the opportunity to leverage fully supported, regionally impactful campaigns; and ultimately, achieved better results for our demand generation campaigns.

Learning 1: When starting the process of shifting to an Agile approach, there is an advantage in letting the GTM team form, storm, and norm before involving the EMEA team. That delay allows for the EMEA team to finish up previously committed (sales-agreed-upon) deliverables. It gives the team and the sales stakeholders time to observe and see the benefits of Agile GTM teams without feeling that they are not getting the support they were expecting.

The practice: virtual, inclusive PI planning

Our model continues to evolve in a positive way. We’ve now been through five PI planning events and have transitioned from a “one EMEA representative” approach to including our full marketing team in a truly global planning event.

What does a global planning event look like in practice?

When our EMEA team started to participate in PI planning, we had one representative join to understand the process and feed the critical milestones into the team’s plans. We then matured to the full team joining remotely, which meant that we needed to create a system that would enable inclusive planning across continents.

We created a process of “continuous planning.” First, our global team would plan “together,” from Austin and virtually via web conferencing for EMEA. Our EMEA teams would log off during the evenings in their time zones, and the US team would continue to plan with recorded readouts. The next morning, while the US teams were offline, the EMEA teams would listen to the readouts, adapt plans accordingly, and provide their own readouts on changes made once the team was back together during mutual business hours. While tricky at first, this process ensured that everyone was engaged and that all teams’ contributions were heard and considered. Most recently, we’ve conducted fully virtual planning in mutual time zones.

Learning 2: The gradual inclusion in PI planning meant the GTM teams were already well-established and well-versed in the process. The maturity of the teams and the process helped a lot in the inclusion of the international team.

The results: greater alignment, faster time-to-market, better campaigns

Agile Program Management

The impact of our EMEA Agile program can be broken down into three main categories: alignment, time, and utilization.

The collaboration between the EMEA and GTM teams has created significantly stronger connection and alignment, evidenced by both the improvement in campaign quality and our working practices. Our teams have increased visibility into shared and separate work and developed a better understanding of how decisions impact overarching shared goals.

Our Agile ceremonies, combined with the use of Planview LeanKit, have served as a catalyst and a framework to bring us closer together. Communication is easier, more frequent, and more productive, as everyone is aligned to the same goals and plans and has visibility into each other’s progress, needs, and capacity. The greater team can now make conscious trade-offs based on mutual priorities, which enables the EMEA team to focus on the right things and deemphasize asks that are not aligned to the goals. EMEA marketers feel more involved and have an important seat at the table. That is both motivating and effective.

Learning 3: Ceremonies and visual planning tools are absolutely necessary, but only really benefit teams with the right enablement and coaching. To this day we still meet weekly with our Agile coach to refine our LeanKit board and discuss WIP limits, sizing, retros, etc.

From a time-to-market perspective, we’ve seen substantial improvements. Before aligning EMEA to the GTM teams, there were delays in deploying campaigns because EMEA would “find out” about campaigns rather than being part of them from the beginning. Now, the team can give early input and feedback on how a campaign could be adapted to provide the most impact for EMEA, then roll it out more quickly. As a concrete example, we have reduced the time for campaign tactics to go live from three months to three weeks.

The volume and quality of campaigns and campaign materials has increased significantly as well. In the past, the EMEA team often made do with the materials (especially translated materials) that were available, not the assets that were ideal. There were campaign ideas that we could not realize due to a lack of localized material. Without dedicated resources for EMEA, the team had to share creative and translation services with North American providers, who often needed to prioritize programs led by corporate/North America.

Now that EMEA has full visibility into the North American programs, they know what kind of material is in development.

Scaled Agile

They give input on what is needed to execute campaigns in global markets and when delivery will happen. That means EMEA campaigns can begin at almost the same time as the North American ones, and their marketers can prepare for when translated assets and other materials will be available.

Overall, by transforming our EMEA Agile program, the region went from running one or two campaigns each PI to running five campaigns per PI. EMEA marketing went from approximately four to six new localized assets/materials per year to 18 – 20. We added three translated, campaign-specific landing pages per language. And, most importantly, we’re beginning to see direct indication of pipeline improvements.

Agile program management can be challenging with international, distributed teams. By integrating our global team members into our planning processes from the beginning of our Agile transformation, we’ve been able to achieve measurable benefits across the marketing organization.

About Verena Bergfors

Verena is the Marketing Director for Planview’s EMEA markets

Verena is the Marketing Director for Planview’s EMEA markets. She’s from Germany but moved to Sweden around 10 years ago and has been with Planview for over four years. Prior to living in Sweden, she worked in Shanghai for seven years where she held positions in marketing and sales. Verena’s true passion is languages and she enjoys working on diverse international teams.

View all posts by Verena Bergfors

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Use WSJF to Inspire a Successful SAFe Adoption

Read the Blog Post

Stories from the Field: Coaching SAFe in Government

Safe Business Agility

In this ongoing series, our customers and partners share their stories from the field about working with SAFe ceremonies, implementing SAFe, and fostering business agility. In this episode, Phil Gardiner, enterprise Agile coach at SAIC (a Scaled Agile partner) talks to us about his coaching experiences in the public sector, including how “business agility” can be applied in government and some interesting a-ha moments.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Subscribe

Share:

Visit these links to learn more about SAFe in the government space referenced in the podcast:

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Visit Melissa Reeve’s Bio

Guest: Phil Gardiner 

Phil Gardiner

Phil Gardiner is on a mission to help organizations transform the way they work. Having served as an internal change agent, an enterprise coach, and a ‘coaches’ coach,’ Phil has enabled large-scale Lean-Agile transformations within the telecom, entertainment, finance, cybersecurity, healthcare, and government markets. His current focus is to enable people within the federal government space achieve greater business agility within their agencies and programs.

Stories from the Field: Remote PI Planning at CVS Health

Safe Business Agility

In this podcast series, we talk to customers about their field experiences with remote SAFe ceremonies and implementations. In this episode, we talk with Rebecca Davis, SPCT at CVS Health and member of the company’s Agile Transformation leadership team, about fully remote, distributed PI Planning at CVS Health.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Subscribe

Share:

Detail Page

This In this podcast series, we talk to customers about their field experiences with remote SAFe ceremonies and implementations. In this episode, we talk with Rebecca Davis, SPCT at CVS Health and member of the company’s Agile Transformation leadership team, about fully remote, distributed PI Planning at CVS Health.

Visit this link to watch the video referenced in the podcast:

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Visit Melissa Reeve’s Bio

Guest: Rebecca Davis

Rebecca Davis is an iSPCT and leader within the Agile Transformation

Rebecca Davis is an iSPCT and leader within the Agile Transformation Office of CVS Health Digital. She helps the people who do the work become empowered, authentic decision makers, while guiding internal SPCs to mature and excel at leading their individual areas.

Learn How Planview Executed a Successful Virtual PI Planning – Agility Planning

Posted on
Virtual PI Planning

Program increment (PI) Planning plays a critical role in ensuring cross-team alignment and collaboration. Typically done as a two-day, in-person event, PI Planning brings teams and leadership together to create program plans based on a shared mission and vision. As our marketing team approached its most recent PI Planning, we faced a challenge: how could we execute a successful PI Planning event in a completely virtual way?

The answer: surprisingly well. In our recent webinar, We Survived Virtual PI Planning, event participants shared how we prepared for virtual PI Planning, what went well, and lessons learned. In this blog post, we take a closer look at how the Planview go-to-market (GTM) ART not only survived virtual PI Planning but pulled it off with flying colors.

Before the event: The importance of preparation

All of the webinar panelists emphasized the importance of preparation. “Preparation always matters for a PI event,” explained Agile Coach Steve Wolfe from Peak Agility. “But it matters even more for a virtual event. We wanted to make sure that we covered every possible item and contingency.”

Steve and I (our part-time RTE) began planning for the virtual event several weeks before it occurred, using a T-minus calendar to ensure conversations started early and occurred often. We first decided on communication platforms, selecting existing enterprise channels Zoom and Slack for ease of use and familiarity. With the standard whiteboards and sticky notes off the table for planning itself, we looked to Planview LeanKit as our visualization tool. Next, we considered timing. Two full days felt long even in person, so we elected to spread the event out over four half-days, in the morning in North America, which ended up being a critical component of the virtual PI planning event’s success.

We developed the event agenda with even greater attention to detail than usual. We consciously limited the number of time people spent just listening, added a dedicated number of inter-and cross-team breakout sessions, and cut back on vision and context content while making it more interactive with an executive Q&A session. In addition, we ran orientation sessions before the virtual PI planning event with leaders, teams, facilitators, and scrum masters to set expectations. We sent out recordings to walk people through the structure of the event and detailed process documentation to explain prep work needed and desired outcomes.

At the team level, leaders like the Director of Product Marketing and GTM Head Brook Appelbaum focused on gaining the vision and context necessary to guide PI planning. “We met with leadership early and often to discuss what was going on with our business and customers,” Brook elaborated. “Now that everyone was distributed, what did it mean for our programs? This gave us direction on how to pause, pivot, or persist with our campaigns and shape our collective understanding of our business going into virtual PI Planning.”

Brook and her peers complemented their meetings with executives, sales, and customer success leaders with a metrics deep dive. “We went through the numbers to see where we were from a pipeline perspective and the details of our programs and campaigns, down to the media, tactics, and channels,” she continued. “It gave us greater insight into what was performing well and what needed to be adjusted.” We also held brainstorming sessions, facilitated by panelist Leyna O’Quinn, content strategist and scrum master. The team talked through their ideas, then compared their inputs to their current backlog items and reprioritized accordingly. This allowed them to bring the most current thinking into PI planning.

Leyna helped the team finish work in progress from its current PI as well, so they could prepare for their final demo and review their backlog. They reviewed metrics, within LeanKit, from the current PI to see what worked and what didn’t, including:

  • Queues, to reflect each work item’s total lifecycle
  • Lead time and cycle time, to understand how long it takes for work to flow through the process
  • Throughput, with information like completed cards per day or week and story points for interaction
  • Cumulative flow, as a visual representation of work in progress as it flows

According to Leyna, “These visual reports and ceremonies allowed the team to have an open dialog and discuss ways to improve processes, tweak our board, and create a culture of continuous improvement.”

During the event: Synchronous engagement and executive commitment

With their thorough preparation behind them, the GTM ART kicked off its fifth PI Planning event—and first fully virtual event.

It quickly became clear that the four half-day approaches was a winner. Head of EMEA Marketing Verena Bergfors described why it mattered to her team. “When it was a two-day event, we couldn’t participate in the whole thing because of the time difference. We had to listen to recordings from the previous day to try to catch up and provide relevant feedback. With the virtual event, we could read out live with everyone listening and adjust and adapt in real-time. It was the first real PI planning that the EMEA team has been able to fully participate in.”

Chief Marketing Officer Cameron van Orman praised the four-day format as well. “Before we went all virtual, we were talking about flying the whole EMEA team out here for face-to-face planning,” Cameron laughed. “There would have been a real cost to that, not just financial but also time and opportunity cost. When we were forced to do it virtually, we saw the power and impact of synchronously planning together across all of our regions.”

Director of Corporate Marketing Leslie Marcotte echoed these sentiments. For her, the virtual PI Planning event allowed for greater collaboration between her shared services organization and the go-to-market teams. The process made work items, like key milestones and deliverables for shared services teams, much more visible and allowed the groups to identify dependencies, increase collaboration, and foster the right conversations. The cross-team breakout sessions were particularly impactful. “It’s much clearer to me how I connect and how I can engage with different teams across the business,” Leslie said.

Virtual PI Planning

One of the unexpected benefits of virtual PI Planning played out during the event. During in-person PI planning, executives often pop in and out of sessions, listening to and steering discussions. On reflection, executives and participants alike agreed that this approach could be intrusive and distracting. At the virtual PI Planning event, leaders like Cameron could listen in the background and chime in when appropriate without changing the dynamic of the conversation. It also offered the opportunity for structured time with executives. Planview CEO Greg Gilmore spent 30 minutes with the virtual team communicating his vision while taking questions to create engagement.

The team’s visualization tool of choice also made a big difference to virtual PI Planning. Agile Coach Steve explained, “LeanKit became essential, enabling us to visualize the whole plan across the entire value stream. Each team had a section to develop their plan during breakouts based on a two-week delivery timeframe. We used colors and cards to quickly visualize the work of each team and connected cards to see dependencies. Boards included links to Zoom breakouts and Slack channels, so from one board, you could get to wherever you needed to go. We used LeanKit before, during, and after the event for everything from readouts to the final confidence vote. It is a powerful tool and a key enabler for pulling off a successful event.”

After the event: Hardening, validation, and continuous improvement

Following the successful conclusion of the four-day virtual PI Planning event, the team focused on validation. “We spent the next week on hardening our plan,” Brook said. “We dedicated time to reviewing and overcommunicating our plans to make sure everyone was on board.” This included readouts in numerous business steering meetings, all the way up to the Board of Directors. The team used its LeanKit boards in those conversations to demonstrate its plans and achieve further alignment.

With their plans validated, the GTM ART went into execution ceremonies and cadences. Immediately after the virtual PI planning event, they hit the ground running with an LPM T-minus calendar. They plan to drive continuous improvement through ongoing communication and collaboration with the business and consistent metrics deep dives that show how they are performing mid-flight, not only at the end of the PI cycle.

Top 5 lessons learned

  1. Prepare thoughtfully and thoroughly. Focus on vision, context, and programs during preparation to create the guardrails that help define plans but resist the urge to go too far into tasks and items before the event.
  2. Create a visual collaboration space. Enterprise-class tooling is critical. Rethink how you can use tools like LeanKit to replace whiteboards and sticky notes and enhance collaboration.
  3. Utilize cross-team breakouts. Every participant in the GTM ART’s virtual PI Planning event found tremendous value in the cross-team breakouts, from tactical benefits to greater empathy for their colleagues.
  4. Engage your executives. An engaged but unobtrusive executive presence demonstrated commitment to the process and the people involved in PI Planning.
  5. Respect your team’s humanness. Virtual PI Planning only worked because its leaders thought hard about the experience. From the four-day structure to frequent breaks to mitigating Zoom fatigue to greater inclusion of global teams, all participants agreed that the event worked well because they were intentional about how it was structured.

“If you’re doing Agile and you’re thinking about doing PI Planning, but you’re hesitant because of the virtual workforce, just do it,” concluded Cameron. “Think about the prep work, visual collaboration, and technology enablers. Have clear outcomes, objectives, and roles. As a business, you can’t wait weeks or months hoping that it will go back to the way it used to be; alignment, shifts, and changes are too important. It may be messy, but there are a lot of things that are better in an all-virtual environment.”

About Emily Peterson

Emily Peterson

Emily Peterson is a demand-gen strategist for Planview’s Lean & Agile Delivery Solution and serves as a part-time RTE for the Go-To-Market Agile Release Train. She uses her professional experience in Agile marketing to leverage new ways of working across the organization, connecting all parts of the business to the overall goals of the organization.

View all posts by Emily Peterson

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Product Owners, Product Managers, and the Feature Factory

Read the Blog Post