Topic: Starting SAFe

A Product Owner’s Answer to Who Writes User Stories in SAFe

Posted on

Who writes user stories? 

Based on the Product Owner (PO) Framework article, POs manage and prioritize the team backlog. 

However, this doesn’t directly answer who writes user stories. Does managing and prioritizing include writing stories? Should POs write most or all of the stories? Or should the Agile Teams? 

This question arose when a new PO asked me for ideas for her team. She asked me, “Who writes the stories on your team?”  

Although I gave the new PO an answer about my team, how we worked, and shared who touches stories, this basic question stayed with me. 

Who should write the user stories? 

Here are three potential answers to consider:

  • Agile teams should write the user stories
  • POs should write the user stories
  • It depends on the situation

I’ll explain my reasoning and how I reached for SAFe® guidance considering each possible answer. I also hope you’ll check out the user story-writing resources at the end of this post.

How to determine who should write user stories

When Agile teams should write the user stories

Lean-Agile leaders have acknowledged a game-changing truth: attempting to ‘manage’ knowledge workers with traditional task management is counterproductive. Management visionary Peter Drucker was one of the first to point this out: “That [knowledge workers] know more about their job than anybody else in the organization is part of the definition of knowledge workers.

—SAFe Principle #8 article

To help answer the question of who writes user stories, I turned first to SAFe Principle #8, Unlock the intrinsic motivation of knowledge workers.

The importance of unlocking the intrinsic motivation of knowledge workers was never more apparent to me than when I became a PO. Many of my teammates had more experience with their expertise area and working on our courses than I did. 

This applies across many fields, products, and enterprises: your teammates become experts in what they are doing because most of us want to succeed at work. Thinking about how to help your team individually and collectively find motivation is key, and recognizing team members’ expertise is a crucial way to build trust and respect to lead the work effectively. 

The language in Principle #8 reminds me to define my role and sphere of influence. As a PO, I don’t manage people. However, for my team to produce great learning content, I must care about their knowledge, ideas, experiences, and expertise at each juncture of planning, refining, and iterating on the work they’re doing. 

On my team, Agile teammates usually write user stories. Every teammate has expertise that I don’t have. It would be foolish of me as a PO to write every story when someone else on my team understands the details about accomplishing the work more than I do. 

If I tried to represent their work by defining and writing every story, it could lead to too much rewriting. Rewriting a story is fine as we refine and understand more details and can often be done as a team activity alongside Backlog Refinement, estimation, and even Iteration Planning and it can be streamlined when the right expertise is applied as the story is discussed. 

If I wrote every story, I’d probably have to consult on and rewrite plenty (most) of them. Worse, it could demotivate my teammates if every story was dictated by their PO. 

That said, what I do as my team refines stories is:

1. Provide a strong voice in crafting acceptance criteria

2. Remind the team of our definition of done for work

3. Share who the customer is, and what they want

4. Work with the team (collectively and individually) on what counts as a “minimum viable story” for our backlog. 

You’ll find an example of a minimum viable story at the end of this post.

Why POs should manage, but not always write, user stories

While any team member can write stories at any time, it is the PO’s responsibility to ensure that they are well-formed and aligned with product strategy. The PO clarifies story details, applies user-story voice, ensures ‘INVEST’ characteristics are present, assists with story splitting, defines enablers, and incorporates behavior-driven design (BDD) to ensure stories support continuous value flow. The PO also allows space for ‘local’ stories and spikes that advance product design but are not derived explicitly from ART-level features.

—Product Owner article

My second answer to who writes user stories comes from the PO Framework article. 

POs “manage”  the team’s backlog and have content authority. This can mistakenly turn into an expectation that POs write the stories.

POs may write all the stories if:

1. Agile teams are not yet feeling the benefits of transformation. Therefore, they may be slow to embrace the work of writing stories themselves. It can become “another thing to do” or “taking time away from doing the actual work.” 

2. They want to ensure the ART and team backlogs are aligned, and stories in the team’s backlog meet the definition of done and support ART progress.

However, if the PO writes every story, they will have little time to perform all the functions POs are otherwise busy with!

For me, it’s important to note the Framework talks about management, not authorship. In fact, the PO article talks about guiding story creation rather than authoring stories.

We don’t find SAFe specifying that POs author the team backlog. What a PO does in order to manage the backlog and guide story creation is both different and deeper than simply writing everything in it:

  • Strategizing across the ART to meet ART-level objectives
  • Working with Product Managers, Business Owners, and the RTE to deeply understand the matrix of metrics the ART is using, strategic themes, and how both are applied 
  • Working closely with Product Managers, who own the ART Backlog, to refine features
  • Working closely with the team and stakeholders to decompose features into stories
  • Ensuring stories meet user needs and satisfy the team’s definition of done
  • Being the go-to person to share decisions the team is making on “how” to complete the work and how it may show up in meeting objectives
  • Prioritizing which work to do when so the team can accomplish its goals and contribute to the ART goals while maintaining flow

Here is the guidance I shared with another PO on the idea of the PO writing every story.

Becoming a story-writing PO will:

  • Create demonstrable work for the PO
  • Codify the (damaging) idea that writing stories is a bureaucratic task
  • Lead to future disagreements or dissatisfaction about what should be included in the scope of this work
  • Set POs up to be the target for those disagreements and dissatisfactions

Here’s what it won’t do. 

It won’t remove the need for teams to plan their work together to achieve flow or avoid rework or misunderstandings about what value is being delivered or how the team is delivering it.

For these reasons, I refuse to become a story-writing PO. I insist my team come together to discuss work and decide who is best informed to write a story. I further drive us to consider all of our stories in refinement so there are multiple teammate eyes on it. 

The immediate result of this process with some of my teammates early on was frustration: “I’m so busy that asking me to write about my work instead of doing it feels like you’re wasting my time.” 

Over time, it has borne other, much more nourishing fruit for the team, including: 

  • More paired work and team stories
  • Better flow and processes to manage flow
  • Growth of T-shaped skills
  • Improved understanding and thought about customer centricity across the team
  • An understanding of each other’s areas of expertise and how work connects on a cross-functional team

If you have teammates who resist writing stories, I recommend you surface this conflict sooner than later and work through it upfront.

The most knowledgeable people write the user stories

I believe the best answer to who writes user stories is the answer to “Who knows the most about this work?” 

Sometimes the answer may be the PO because they’ve gathered the most information. 

In this case, it’s best for the PO to write the story. 

  1. I have been in an org-wide or ART-level meeting and know about work for every team. This has included tooling updates, requests to prepare specific demos of our work for different kinds of audiences, work around specific milestones, or professional development requests. 
  2. It is work that came out of my meetings with other teams to service dependencies. 
  3. It is walk-up work coming from changes or needs that weren’t surfaced before. 
  4. Talking with an internal or external customer helped me understand a need we had not previously written stories to meet.

It is rare I would write a story for work I am doing. In the above cases, the work would be handled by the team. By writing the story, I am capturing the need as I understand it but not carving the story in stone. 

When thinking of how stories enter the backlog, I find it useful to remember the three Cs of story writing: 

  • Card
  • Conversation
  • Confirmation

The C for conversation is most relevant to my mindset on this. The story is a promise our team will discuss this need and decide how to deliver value on it. 

The conversation could include: 

  • Refining our understanding of the user and their need
  • Revising acceptance criteria
  • Discussing who might start the work on it or how the team will deliver the work’s value 

This is the minimum viable story criteria my team uses.

Example of a minimum viable user story

1. Story title: Provide a name that accurately describes the work
2. What: Give a description of the work
3. Activities or tasks: Break down what it will take to complete this work
4. Acceptance criteria: This answers the question, “What can we or our customers do now that we or they could not before?” or “How will we know this is done?”
5. Parent: Connect it to a feature where possible
6. Tags: We note if this is a team story (more than one person tagged) or an individual contributor’s work (a single person tagged)
7. PI and Iteration: When we expect to start and complete this work

I encourage you to use this template as a jumping-off point. 

Look through your backlog and think about who is and could write user stories with the most thoughtful details.

Story-writing resources

Now that I’ve shared my answer to who writes user stories, here are some resources to help write them.

If you want to receive helpful content like this for your role, don’t forget to set your role in SAFe Studio. This allows us to bring the best content to your SAFe Studio homepage. Set your role in SAFe Studio today.

Set your role in SAFe Studio Log in now

About Christie Veitch

As a writer and education nerd who loves processes, Christie seeks to move the needle on what learners can do and what educators and trainers will try with learners. She designs and delivers compelling content and training and builds communities of avid fans using these resources as a Scaled Agile, Inc. Product Owner. Connect with Christie on LinkedIn.

Kick-starting the SAFe Journey at a Traditional Organization – Implementing SAFe

Posted on

It’s incredible that the Scaled Agile Framework® (SAFe®) is now 10 years old, and the Agile Manifesto is now over 21 years old. What began in software development is now expanding to encompass the entire enterprise, changing how people work and how every aspect of business is run.

In the last few years, the COVID-19 pandemic has accelerated the need for and execution of digital transformation. Yet, many organizations are still struggling to get business results from their investments or haven’t made them at all.

To compete in this new era, these companies must look at agility as a core business competency. Many of these traditional organizations are looking for a playbook they can follow as they embark on their agility journeys. In my experience, organizations come from one of the following contexts:

  • The organization has done a successful pilot (typically with a small number of Agile teams) and now wants to scale to the rest of the business unit or line of business (which is NOT yet Agile)
  • An organization wants to implement SAFe to address its defined burning platform
  • A consultant has done an assessment and recommends initiating an Agile transformation
  • Some combination of the first three

Regardless of an organization’s starting point, it’s important to understand the current state of transformation and validate assumptions with due diligence before creating a path forward.

Before beginning, perform due diligence

For a transformation to succeed, it’s crucial that organizations articulate the “why” tipping point for their journey before they begin. In addition, it’s important for organizations to gather data points to validate any success patterns they have experienced using the SAFe Implementation Roadmap. Some of the questions to ask regarding this due diligence (in no particular sequence) include:

  • What change agent and team member training is completed and planned?
  • What is the current state of the foundational building block (Agile team)?
  • Which steps of the SAFe Implementation Roadmap have been completed?
  • Which SAFe configuration are you using and why?

Answers to these powerful questions bring organizations clarity about the purpose for their transformation and alignment through awareness of their true current state.

Kick-start the Transformation with This Approach

Various factors influence the decision to move forward with a SAFe implementation. For more traditional organizations with a waterfall or hybrid mindset, unaligned ways of working, and inconsistent terminology interpretation, the below transformation approach can help shape their paths.

Create and measure a maturity baseline

Having a simple maturity model without new terminology is crucial, and organizations should define one that works for their context. HCL Technologies, a next-generation global technology company, designed a maturity model (see Figure one) to set a baseline in a traditional organization, business unit, or line of business. This model, which can be tweaked given the client’s context, captures key characteristics of an organization on various dimensions.

SAFe implementation
Figure 1. Organization Maturity Model example

Keep in mind that in many situations, assessment “fatigue” is also real. So it’s critical to design and administer maturity measurements effectively with minimally invasive approaches, including the right combination of:

  • Interviews (one-on-one and/or in group settings)
  • Observations from attending various meetings
  • Simple assessments (eight to nine questions)

Putting it into practice: evidence from the field

HCL requested to lead the transformation for a client in the health industry using a hybrid SAFe methodology. The client organization had six ARTs and over 400 people involved in development, testing, and support. By conducting role interviews (Architect, RTE, Product Management, executive leadership, and so on) at various levels of the organization, HCL gathered the necessary data points to set a baseline for the client’s maturity level.

HCL also conducted 18 detailed, one-on-one interviews and observed several ongoing meetings and events for three weeks. They used a similar maturity model to Figure one, which helped establish alignment for priority and focus areas.

When another client organization in the pharmaceutical industry assessed the workforce enablement dimension of its current state, it found no or inconsistent use of tooling. Upon discovering this, leadership aligned and identified tooling as an opportunity and key enabler for the company’s digital strategy execution.

Script the critical moves

With relevant data points from baseline measurements, highlight the bright spots and rationalize target maturity level with relentless socialization for buy-in and alignment. Defining building blocks, or pieces of work, is the next key element in this approach, with categories like:

  • Organizational readiness
  • Content readiness
  • Logistics and planning event readiness
  • Enablers

Putting it into practice: evidence from the field

One of the crucial aspects of making this approach palatable for the health industry client was meeting the client where they were. Providing maturity model dimensions mapped to proven PI readiness success patterns helped accomplish that and reduced the cognitive load of transformation change because the client didn’t have to learn new terminology.

Data points from the maturity assessment findings helped the client prioritize specific readiness aspects before the first PI Planning event. Here are some examples of these readiness aspects:

  1. Case for change and communication strategy (organization readiness)
  2. Capacity allocation for various work types (organization readiness)
  3. Capacity allocation of subject matter experts for enablers (content readiness)
  4. Team topology at the ART and team levels (organization readiness)
  5. Training and workshops, including SAFe® for Teams, before PI Planning (enabler)

The transformation team at the pharmaceutical client’s organization prioritized standardized tooling by implementing Jira Align at the enterprise level. This tool provided a central location for all work and enabled visibility of all work types.

Shrink and scale the change

After the building blocks are designed, the next key element is to “shrink the change” to reduce business disruption. Building blocks provide the opportunity to shrink change and make it more digestible. Initial success as small as one ART motivates the broader organization and provides a blueprint for replication.

Design building blocks in a way that provides the flexibility to shrink change first and scale from one ART to multiple ARTs or from Essential SAFe to Full SAFe later. Based on complexity, baseline maturity level, solution size, and development value stream(s) involved, the organization can establish either:

  • Eight to 12 weeks of runway preparedness (see 10 weeks translated into five iterations in Figure two) or
  • Eight to 12 weeks of executing a readiness plan before the first official planning event launch
SAFe implementation
Figure 2. Mapping Maturity Model Dimensions to Scalable Building Blocks for PI Readiness

Putting it into practice: evidence from the field

After prioritizing readiness building blocks for organization readiness, content readiness, and enablers, it took 10 weeks for the health industry client to create and socialize the readiness plan and align stakeholders. It took an additional 10 weeks to implement the plan. Once this client implemented backlogs and boards to visualize their work, they experienced improved coordination and dependency management and better visibility and transparency across ARTs.

Before implementing Jira Align at the pharmaceutical organization’s enterprise level, the organization’s transformation team developed an implementation roadmap, which included multiple rolling wave phases across the program and portfolio.

Experience Benefits without a New Language

While there is value in using SAFe toolkits and resources, those require an understanding of SAFe terminology. For traditional organizations that prefer to begin their transformation journey without learning a new language, the steps outlined above have generated desirable outcomes with reduced risk.

Putting it into practice: evidence from the field

As a result of this transformation approach, the healthcare client experienced the following positive business outcomes:

  • A single solution backlog across all ARTs of the solution train, a focus on enablers, and improved overall flow
  • Improved defect resolution lead time by 35 percent
  • Changes in value delivery and ways of working, specifically a QA shift left, resulting in quality improvements of 27 percent in lower environments
  • Crucial data points to strengthen the business case for traditional software development life cycle (SDLC) to move toward Agile SDLC through lean governance and process automation for better user experience

The pharmaceutical client experienced the following positive business outcomes from its enterprise-level Jira Align implementation:

  • Agile teams supported in capacity allocation, overall planning, and road mapping activities
  • Predictable delivery with fully aligned organizations across every level of scale
  • Aligned strategy through a federated, unified platform spanning program, product, portfolio, and development team layers (level of scale)

This transformation approach can be customized to fit other use cases with simple tweaks. Read my next post (coming soon) to learn more about other use cases.

About Bharat Shah

Bharat Shah is an SPCT candidate, certified architect, and trainer

Bharat Shah is an SPCT candidate, certified architect, and trainer who has trained over 800 participants in Lean-Agile and DevOps transformation. He is passionate about digital business and driving enterprise-scale business agility journeys.

About Tracey Orphey

racey Orphey is a SAFe-certified Release Train Engineer

Tracey Orphey is a SAFe-certified Release Train Engineer and PROSCI-certified Change Practitioner with an extensive background in digital transformations and Agile programs. She is known for her authentic and forthright approach to cutting through the noise of transformation and has successfully managed change and training programs across various industries.

Experiences Using the IJI SAFe Principle Cards – Benefits of SAFe

Posted on

Games to play with leaders and teams to embed the principles in your organization.

IJI Principle Cards

It’s been over two years since we first launched our popular SAFe® Principle cards. With the advent of SAFe version 5.0, the introduction of a new 10th principle and the launch of a new, updated set of principle cards, it’s a great time to look back at how we’ve been using the cards and the benefits they’ve generated.

This blog post is split into four sections, covering:

  1. A brief introduction to the cards (and where to get them)
  2. Engaging executives and other leaders
  3. Reflecting on how well the principles are being applied
  4. Brightening up training events

A brief introduction to the cards

As one of the first SPCTs in Europe, I’ve delivered more than my fair share of Implementing SAFe® and Leading SAFe® courses, and, to be completely honest, I’ve always struggled to get through all of the principles (I’m usually flagging by principle 6 or 7) and thought there must be some way to make them more accessible. To me, it always felt like we were learning the theory behind the principles rather than getting excited about the principles themselves.

Whilst co-teaching with my colleague, and fellow SAFe Fellow, Brian Tucker, I tried to come up with a simpler, more accessible way for people to engage with, sign up to, and remember the principles. The end result was the set of Ivar Jacobson International (IJI) SAFe Principle cards, now updated with the new 10th principle—Organize Around Value.

IJI Principle Cards

The cards try to do a number of things. For each principle, they:

  • Explain why the principle is important
  • Describe it in a form that is more like a principle and less like an instruction
  • Provide a snappy quote or aphorism that can be used to support it
  • Bring it to life with examples of what awesome and awful behaviour would look like
IJI Principle Cards

All on something the size of a small playing card.

In the old days, the full set would readily fit on one sheet of paper, but now with the introduction of the new 10th principle, we’ve had to expand to two sheets of paper.

The cards are freely available from the IJI website here.

Engaging executives and other leaders

Our experience with executives is that you are unlikely to get them to attend a two-day course or sit through an hour or more’s lecture on the SAFe Principles. They will play the penny game, but their appetite for being talked at is minimal.

This is a shame, as it is absolutely essential that they support and embody the principles in their day-to-day work.

Using the SAFe Principle cards to play the ‘principle ranking’ game, we’ve found that we can get them to engage with, understand, discuss and sign up to the SAFe Principles—all in under 30 minutes (20 is usually enough).

The game itself is very simple and can be played in a number of ways.

It is best played in groups of 3 – 4 people, as this maximizes discussion and ensures that everyone stays engaged throughout.

Equipment: One set of cut cards for each group and one set of uncut cards for each participant. The cut cards will be used to play the game and the uncut cards as a reference. If you want to look up a specific principle, it’s a lot easier to find it on the uncut set of cards than in a pack of cut cards.

The game: Give each group a set of cut principle cards and ask them to rank them in importance to the execution of their business. Separate any that don’t apply, or that they explicitly disagree with, from those that they would actively support.

Once the groups have finished their rankings, ask them if there are any principles they would discard.  We’ve done this many times, at many different organizations, in many different industries and no one has ever discounted or rejected any of the principles. There are a number of ways to produce the ranking:

  • Higher/lower. Someone takes the lead and places the first card on the table. The group discusses and makes sure they understand the principle. The next principle is then selected, discussed, and placed higher or lower relative to the ones already in play. The game continues until all cards are placed.
  • Turn-based. A more formal variation of the previous approach where the members of the group take turns to either add a card to the ranking or reposition one of the cards that have already been played, explaining and discussing their justification as they place or move the cards. The game continues until no one wants to move any of the cards.
  • Four piles. A simplified ranking where you distinguish the top three, the bottom three, and any rejected cards, and leave those not selected in a pile in the middle. This usually results in three piles as typically none are rejected.

Whichever way you choose to rank the cards, remember that it is OK for cards to have the same rank.

The results of the ranking can be interesting, particularly the difference between the different groups—but really this is just a forcing function to make them play with the cards. These pictures show the results from playing this game with a company’s IT leadership team. I’ll leave it as an exercise for the reader to spot which group was the architecture team.

IJI Principle Cards

The real goal of the exercise though isn’t the ranking itself; it’s to get everyone actively engaged with and discussing the principles. The discussions can get quite lively with the participants often referring to the awesome/awful caricatures as well as the descriptions of the principles themselves.

As mentioned above, we’ve never seen any of the principles rejected but we have seen many different rankings. Rankings that often reflect the executive’s area of responsibility— for example, the CFO will typically place the cards in a different order to the head of human resources (HR).

This activity has always gone down really well—it’s active learning, engages everyone in the discussion and doesn’t take a lot of time. It has been so well received we’ve had executives ask to take the cards away to share with their teams. In one case, the head of HR grabbed one of the cards and said, “This is just what I need. I thought one of the ‘Agile’ team leaders was encouraging the wrong behaviours, but I had nothing to challenge them with.”

A good trick to close out the activity is to ask them, as they now understand the principles, “Would you be prepared to sign up to them?” If they say yes, take an uncut set of cards and get them all to physically sign them.

We’ve found that this exercise works almost as well in a virtual environment as it does face-to-face. Using tools such as Mural, it is possible to create an interactive experience that is close to that of playing with the cards face-to-face (but let’s be honest, nothing beats standing up with the cards in your hands).

Reflecting on how well the principles are being applied

The cards are a great tool to use in retrospectives to remind people of the principles they should be applying and to generate actions to encourage everyone to be better at applying them.

One simple way is to use them as a trigger for improvements during a retrospective. The two most effective approaches we have used are:

Pick a card. A very simple activity that throws a bit of randomness into the retrospective process. Every so often (every other retro / once a PI), randomly pick one or two cards to discuss and generate ideas for improvement. To make things fun, you could generate your own awesome and awful examples. The more methodical of you might want to work your way through all the principles one at a time—reducing the set of cards to be picked from each retrospective until you’ve got through all 10.

IJI Principle Cards

Value versus practice.

  1. Create a three-by-three grid with the x-axis being how important the principle is to the group (high, medium, low), and the y-axis being how well the principle is being applied (badly, meh, excellently).
  2. For those in the highly important/badly applied section, discuss what is going on, identify specific examples of bad behaviour, and generate concrete actions for improvement.

You can also use the cards to do a simple principle-based assessment. This is a great complement to the SAFe self-assessments and other practice-based assessments.

The simplest approach is to create a ‘happiness radiator’ with four columns (principle, happy face, neutral face, and sad face) and then get the assessors to tick the relevant box—as shown in the photos below. This can be done at the team level, train level, or even for the whole organization. The important thing is that everyone has their own vote—you want to avoid consensus bias as much as possible.

Note: If people are new to the principles, play the ranking game first to ensure that they understand the principle before voting.

IJI Principle Cards
Here are examples of the cards being used in Mural to perform both the ranking exercise and to build a happiness radiator, respectively.
IJI Principle Cards
The Mural Template for both these exercises is freely available from the IJI website here.

These assessments could, of course, be done without using the cards, but we’ve found that having the cards in their hands really helps people relate to the principle and tick the correct boxes. Even when working virtually, being able to see and manipulate the cards is invaluable.

To make life interesting, the feedback can be generated about a specific community or aspect of the framework such as Product Management and Product Ownership. The table below shows a set of results generated at the Global SAFe Summit in 2017. It also shows the results of performing the assessment at a meetup in Amsterdam.

It is scary how few Product Management Teams are exemplifying the SAFe Principles. I was shocked to see that only 13 percent of the SAFe practitioners surveyed at the SAFe Summit (about 100 people) thought that the Product Managers in their organization took an economic view. If the Product Management Team isn’t adhering to our underlying Lean and Agile principles, then I truly believe this will severely limit how Agile and effective the teams can be. If the Product Managers and Product Owners are not behaving in an Agile way, then there is no way that their teams can be truly Agile.

IJI Principle Cards

To help with these role-based assessments, we have produced sets of role-specific principle cards, one of which is shown on the left.

To get access to these cards and for more information on how to use them, go to the main Principle card page here. RTE and Architect cards are also in the works and will be accessible from the same area.

About Ian Spence

Ian Spence is an Agile coach, SAFe® Fellow

Ian Spence is an Agile coach, SAFe® Fellow, and Chief Scientist at Ivar Jacobson International. He has helped literally hundreds of organizations in their Agile transformations by providing leadership, training, consultancy, facilitation and all levels of coaching. An experienced Agile coach, consultant, team leader, analyst, architect, and scrum master, Ian has practical experience of the full project lifecycle and a proven track record of delivery within the highly competitive and challenging IT solutions environment.

View all posts by Ian Spence

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Quarantine and COVID-19: Beware of Burnout

Read the Blog Post

The Tipping Point at Travelport – Implementing SAFe

Safe Business Agility

Listen to a candid conversation about what prompted Travelport to adopt and implement SAFe®. Hint: it partially started with a grassroots movement. Hilla Knapke, director, enterprise transformation office, and Charles Fleet, VP of transformation share their stories, observations, and perspectives.

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

Subscribe

Share:

Listen to a candid conversation about what prompted Travelport to adopt SAFe®. Hint: it partially started with a grassroots movement. Hilla Knapke, director, enterprise transformation office, and Charles Fleet, VP of transformation share their stories, observations, and perspectives on small wins, gaining trust from leadership, learning from failure, dealing with conflict, and more.

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: Hilla Knapke

Hilla Knapke 

Hilla Knapke is director, enterprise transformation at Travelport. She executes strategic portfolios while driving business agility into all aspects of business operation through Travelport’s Corporate Development Office. Hilla excels at leading large-scale, technically complex, high-value, strategic global initiatives, unlocking true business agility within organizations. In her personal time, Hilla is a classically trained musician and an avid soccer fan (raising her own favorite goalkeeper); she enjoys hiking, camping and 4x4ing with her husband and children in the beautiful Colorado mountains.

Guest: Charles Fleet

Charles Fleet

Charles Fleet, VP of transformation at Travelport, has more than 15 years of experience leading strategic, global change initiatives. He excels at creating cohesion in disparate teams, overseeing global delivery relationships, and bolstering innovation in program management. Charles lives in Colorado with his wife and two boys, and enjoys running as well as endlessly tinkering on projects around the house.