Category: Thought Leadership

The SAFe® Coach

Posted on
a group of business professionals studying with a SAFe coach

Coaching appears in the Scaled Agile Framework® (SAFe®), but there isn’t one place where we define the SAFe coach. According to our recent internal survey of 2,500 SAFe Program Consultants (SPCs), over 70 percent are actively engaged in coaching SAFe implementations. In general, a SAFe coach is a servant leader, someone who can facilitate both change and collaboration at scale. A SAFe coach embodies the attributes of our Lean-Agile mindset as well as a learning and growth attitude to lead by example, while continuously fostering positive change. 

A servant leader

There are many roles or labels the coach could play within a SAFe transformation, including Scrum Master, Release Train Engineer, and SPC. Regardless of the roles and functions inherently associated with a coach, coaching takes place throughout all of SAFe’s core competencies. And all of the competencies have one characteristic in common: to guide organizations in fostering better ways of working. So that we can compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions.

Within the competencies, servant leadership is unique. It’s a behavior designed to continuously serve the teams, enable product delivery, and benefit the overall enterprise. Using active listening and the collective mindset and principles of SAFe, a coach as a servant leader can become more aware, and more connected to the people within their organization. This approach brings neutrality to the enterprise. So that people feel safe in voicing their thoughts and opinions, and can collaborate to realize the benefits of shared understanding, innovation, learning, and growth. By embodying servant leadership, a SAFe coach can help the organization increase SAFe’s effectiveness and relentlessly expand collaboration, coordination, knowledge transfer, and consistent information flow. 

A facilitator of change

SAFe’s dual operating system enables efficiency, stability, and the speed of innovation. Another key benefit of this system is the ability to evolve the social structure organized around value: the Agile Release Train (ART). This is brilliant, and as referenced in The Power of Empathetic Leadership in an Evolving World, Chuck Pezeshki writes, “How you set up your social structure is THE critical factor in how knowledge and synergies in design will be created. Using Conway’s Law, one can predict a priori what the functional form of a design will be. It matters who talks to who.” 

By organizing around value and creating the social structure around the ART, we design a social structure that encourages knowledge sharing and helps us use empathy and design thinking to innovate around the value we’re creating for customers. Pezeshki further states, “Inside the social structure, empathy is the dynamic that creates synergies in design. While empathy is always valuable, even within the simplest social structures—people that connect are much more likely to transfer correct information to each other—it is essential in creative enterprises.” In our world of ever-evolving complexity, creating social structures can help us transfer information that is accurate, reduce risk, and continuously increase the speed of delivering value. 

Coaching these social structures or networks is part of SAFe’s approach to the dual operating system. These networks take the form of virtual organizations such as ARTs or Solution Trains. And within these virtual organizations, coaches need to have personal agency as their own values and behaviors, so they can coach empathetically and address change quickly. The coaches are empowered to serve the social structure by using these synergies, creating knowledge flow, and facilitating positive growth and change. 

a group of people having a meeting in a small office space.

A facilitator of collaboration at scale

According to Jean Tabaka, author of Collaboration Explained, Facilitation Skills for Software Project Leaders, there’s an intangible component of team and organizational power fostered by collaboration. That component brings out the best in people, and in turn, the value the enterprise delivers to its customers. 

As agilists, it may seem obvious that collaboration is a key component of building software and systems. It is, after all, called out in the third value of the Agile Manifesto: Customer collaboration over contract negotiation. If your leaders ask you why this is so important as a coach, there’s a deeper understanding of the why that’s reinforced in Jean’s book, and that has decades of history in Lean highlighted in Ikujiro Nonaka’s book The Knowledge-Creating Company. He calls out the tacit knowledge—the valuable and highly subjective insights and intuitions that are in people’s heads and difficult to capture and share. 

Collaboration is what helps make that knowledge transferable, or explicit, within your enterprise. Organizations also benefit from converting tacit knowledge into explicit knowledge because it represents a way to express the inexpressible. When building software and systems at scale, there is obvious complexity. There’s literally no one that has all the knowledge. It’s inherently shared across our valued people across the value streams and the enterprise. It takes thousands, if not tens of thousands of people to build today’s computers, cars, aircraft, and satellites.

This evolution of knowledge sharing helps you grow your business through a culture of understanding and aligning with your company’s overall strategic goals. The expanded mission of SAFe 5.0 is to enable the business agility that is required for enterprises to compete and thrive in the digital age. Facilitating tacit knowledge is critical and supported through the extension, behaviors, and mindset of all the SAFe competencies. It’s also measured through the latest Measure and Grow evaluations of how well the enterprise is progressing toward overall business agility. 

The SAFe coach in the enterprise needs to find ways to coach and continuously improve collaboration. Sharing that tacit knowledge through SAFe events is one of the most powerful ways to allow people to continually innovate and gain the knowledge and collective mindset to integrate and deliver the highest level of value. 

Coaches need coaches, too

A SAFe coach needs an extensive toolbox to evolve and accelerate their organization’s SAFe implementation. There are many tools to support coaches in learning how to be servant leaders and facilitate change and collaboration. None of this comes easy. Can you imagine intuitively knowing how to do all of this in your first SAFe coaching gig? Coaches need coaches, too. We learn from others and vice versa. If we model the SAFe coaching behavior we’d like to evolve, it will become a self-reinforcing learning experience that will enable coaches to help each other, cultures to evolve, and people to be happy and heard. All of this can help us truly become that relentless learning organization that solves some of the world’s largest problems. We could all use a little of that right now.

Here’s where you can learn more about evolving your SAFe coaching expertise: 

Stay tuned for upcoming blog posts on SAFe coaching.

About Jennifer Fawcett

Jennifer Fawcett - a retired, empathetic Lean and Agile leader

Jennifer is a retired, empathetic Lean and Agile leader, practitioner, coach, speaker, and consultant. A SAFe Fellow, she has contributed to and helped develop SAFe content and courseware. Her passion and focus has been in delivering value in the workplace and by creating communities and culture through effective product management, product ownership, executive portfolio coaching, and leadership. She has provided dedicated service in these areas to technology companies for over 35 years.

View all posts by Jennifer Fawcett

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Shared Objectives and Collaborative Sense Making

Read the Blog Post

Agility Fuel – Powering Agile Teams

Posted on
Agility Fuel

One of my favorite analogies for agile teams is to compare them to an F-1 race car. These race cars are the result of some of the most precise, high-performance engineering on the planet, and they have quite a bit in common with high-functioning agile teams. Much like F-1 cars, agile teams require the best people, practices, and support that you can deliver in order to get the best performance out of them.

And just like supercar racing machines, agile teams need fuel in order to run. That fuel is what this post is about. In the agile world, the fuel of choice is feedback. I would like to introduce a new ‘lens’ or way of looking at feedback. I’ll leverage some learning from the art of systems thinking to provide a better understanding of what various metrics are and how they impact our systems every day.

Most often, this feedback is directly from the customer, but there are other types as well. We have feedback regarding our processes and feedback from our machinery itself. In broad terms, the feedback in an agile world falls into three different categories:

  1. Process: Feedback on how the team is performing its agility.
  2. DevOps: This is feedback on the machinery of our development efforts.
  3. Product: The so-called ‘Gemba metrics.’ This segment of feedback is where we learn from actual customer interaction with our product.

Thinking in Feedback

Every agile framework embraces systems thinking as a core principle. In this exercise, we are going to use systems thinking to change how we see, interact with, and make predictions from our feedback. If you want to go deeper into systems, please pick up “Thinking in Systems,” by Donella Meadows or “The Fifth Discipline,” by Peter Senge. Either one of these books is a great introduction to systems thinking, but the first one focuses solely on this topic.

For the purposes of this post, we will be thinking about our feedback in the following format:

Metric

This is the actual metric, or feedback, that we are going to be collecting and monitoring.

Category

Every feedback loop will be a process-, operational-, or product-focused loop.

Stock

Each feedback metric will be impacting some stock within your organization. In each case, we will be talking about how the stock and the feedback are connected to each other.

Type

Balancing: Think of the thermostat in a room; it drives the temperature of the room (the stock) to a specific range and then holds it there. These are balancing feedback loops.

Reinforcing: Because a savings account interest is based on how much is in the account, whenever you add that interest back in, there is more stock (amount in the account) and more interest will be deposited next time. This is a reinforcing feedback loop.

Delay

Feedback always reports on what has already happened. We must understand the minimum delay that each system has built into it, otherwise system behavior will oscillate as we react to the way things used to be.

Limits

We will talk about the limits for each stock/feedback pair so that you can understand them, and know when a system is operating correctly, but has just hit a limit.

A Few Examples

Let’s look at one example metric from each category so that you can see how to look at metrics with this lens.

ART Velocity

Agility Fuel

Discussion:

ART velocity impacts two stocks: Program Backlog and Features Shipped, both of which are metrics themselves. In both cases, ART Velocity is a balancing loop since it is attempting to drive those metrics in particular directions. It drives Program Backlog to zero and Features Shipped steadily upward. In neither case will the stock add back into itself like an interest-bearing savings account.

The upper limit is the release train’s sustainability. So, things like DevOps culture, work-life balance, employee satisfaction, and other such concerns will all come into play in dictating the upper limit of how fast your release train can possibly go. The lower limit here is zero, but of course, coaches and leadership will intervene before that happens.

Percent Unit Test Coverage

Agility Fuel

Discussion:

Percent Unit Test Coverage is a simple metric that encapsulates the likelihood of your deployments going smoothly. The closer this metric is to 100 percent, the less troublesome your product deployments will be. The interesting point here is that the delay is strictly limited by your developers’ integration frequency, or how often they check in code. Your release train can improve the cadence of the metric by simply architecting for a faster check-in cadence.

Top Exit Pages

Agility Fuel

Discussion:

This list of pages will illuminate which ones are the last pages your customers see before going elsewhere. This is very enlightening because any page other than proper logouts, or thank-you-for-your-purchase pages, is possibly problematic. Product teams should be constantly aware of top exit pages that exist anywhere within the customer journey before the value is delivered.

This metric directly impacts your product backlog but is less concerned with how much of anything is in that backlog and more of what is in there. This metric should be initiating conversations about how to remedy any potential problem that the Top Exit pages might be a symptom of.

Caution

Yes, agility fuel is in fact metrics. Actual, meaningful metrics about how things are running in your development shop. But here is the thing about metrics … I have never met a metric that I could not beat, and your developers are no different. So, how do we embrace metrics as a control measure without the agile teams working the metric to optimize their reward at the cost of effective delivery?

The answer is simple: values. In order for anything in this blog post to work, you need to be building a culture that takes care of its people, corrects errors without punitive punishment, and where trust is pervasive in all human interactions. If the leadership cannot trust the team or the team cannot trust its leadership, then these metrics can do much more harm than good. Please proceed with this cautionary note in mind.

Conclusion

This blog post has been a quick intro to a new way of looking at metrics: as agility fuel. In order to make sense of how your high-performance machine is operating you must understand the feedback loops and stocks that those loops impact. If this work interests you, please pay attention to our deep-dive blog posts over on AllisonAgile.com. Soon, we’ll be posting much more in-depth analysis of metrics and how they impact decisions that agile leaders must make.

About Allison Agile

Blog author Lee Allison headshot

Lee Allison is a SAFe 5.0 Program Consultant who implements Scaled Agile across the country. He fell in love with Agile over a decade ago when he saw how positively it can impact people’s work lives. He is the CEO of Allison Agile, LLC, which is central and south Texas’ original Scaled Agile Partner.

View all posts by Allison Agile

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Tips to Pass Your SAFe Exam and Get Certified

Read the Blog Post

Inspect and Adapt: How a 30-year-old PPM Company Became a Case Study in Agile Transformation

Posted on
Agile Transformation

In 2017, Planview (a Scaled Agile partner) realized that its customers and market were evolving beyond their traditional product lines. A leader in project portfolio management (PPM) solutions, Planview recognized the need to adapt both strategically and operationally and looked to Agile to power a much-needed transformation. (Read the full story in Harvard Business Review).

While the development departments had practiced Agile for some time, the larger Planview organization really began its forays into Agile starting in 2017 via the acquisition of a company with strong Agile DNA and a powerful Kanban product. Sporadic successes after the acquisition, however, didn’t translate to the change the company needed. Planview knew that real transformation required a top-down commitment, and in late 2018, established a company-wide goal to rewire its organization through a new Agile Growth Initiative.

The initiative focused on five key objectives:

  1. Infuse agility into the organization by increasing Agile DNA throughout
  2. Admit we couldn’t do it alone and bring in outside coaching support
  3. Embrace Agile practices and ceremonies from leadership to the teams
  4. Reorganize people and teams to focus on customer value
  5. Empower everyone to have a voice and do their best work

Led by the marketing department, Planview brought in external Agile experts as guides and kicked off its first Agile discovery session. When the team asked sales, marketing, and product leaders to list their top priorities, every department was different. It became clear that scaling across functions was the organization’s biggest challenge—and most promising opportunity.

Planview accelerated its Agile initiative by creating three cross-functional Agile teams that comprised the first Go-to-Market Agile Release Train. Through Program Increment (PI) Planning events, the teams shared, according to Harvard Business Review, “… some hard conversations that ultimately resulted in reorganizations and the realignment of people and funds.”

The result: a new emphasis on solutions vs. products that enabled the organization to provide value to their customers in meaningful, innovative ways. With Agile, Planview successfully shifted from a 30-year-old PPM company to an Enterprise Agile Planning Solution Leader. That’s true transformation, although for Planview, it’s simply one more step in a continuous process of inspecting and adapting.

Read the full story of Planview’s transformation in Harvard Business Review.

About Brook Appelbaum

Brook Appelbaum

Brook Appelbaum is the Director of Product Marketing for Planview’s Lean and Agile Delivery Solution. With nearly 20 years of marketing experience, Brook has led many different product and digital marketing teams. However, her favorite leadership role is that of a Product Owner. As part of an Agile marketing team inside Planview, Brook drives the campaign and product marketing strategy for the Lean and Agile Delivery Solution. And she thinks LeanKit is the coolest.

View all posts by Brook Appelbaum

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Scrum Master Stories: Building Relationships

Read the Blog Post

5 Reasons to Attend the European SAFe Summit – Agile Leadership

Posted on

How do you get stakeholders to collaborate on a roadmap? What are the seven deadly sins of Agile portfolio management? How do you avoid a “train” wreck with your ARTs? What are some techniques for managing the modern workforce? How did Travelport create psychological safety among its C-level leaders?

The 2020 European SAFe Summit, 10-11 June in The Hague, will answer all these questions and more: each day we’re adding new sessions designed to make this Summit the best one yet. The European SAFe Summit is the largest conference for the top SAFe practitioners, experts, and thought leaders working in Agile today.

Last year’s attendees gave us a diversity of reasons why they appreciated the European SAFe Summit—from the informative keynotes and practical sessions to the helpful staff and delicious food. But here are my top five reasons for why you won’t want to miss it.

1. Gain access to SAFe insiders

From the SAFe founder Dean Leffingwell to the SAFe Fellows and SPCTs, the Summit gives you the chance to learn from and share feedback with the SAFe leaders whose experiences and thinking to shape the framework. Come to the SPCT coaching station to sit one-on-one with experts and discuss solutions to your unique challenges.

2. Hear from SAFe customers

Come and hear from some of the largest organizations in Europe about how they’re using SAFe to improve their planning, portfolio strategy, product quality, and time-to-market. Leaders and change agents from Europe’s top companies will be presenting their experiences, learnings, and advice for making SAFe work inside your own organization.

3. Learn best practices

We know, and you know, that organizations are complex, messy, and resistant to change. That’s why it’s so helpful to hear what works—and what doesn’t—across different types of environments. We invite SAFe customers, trainers, and framework experts to share their insights at the Summit because attendees tell us again and again how valuable SAFe best practices are in accelerating adoption and supporting a culture of change.

4. Make connections that support your business

As Agile adoption has expanded across Europe, the Agile community has become dedicated, tight, and strong. The Summit unites those of us practicing, leading, and experiencing Agile at scale so you can easily make connections and build your network with other coaches, thought leaders, and change agents. Meet other people working with SAFe, identify opportunities to cultivate working relationships, and evaluate service or platform companies that can accelerate your work.

5. Get in-depth training

Stay through 12 June for a dedicated day of hands-on workshops. Enhance your results—and your professional skills—by diving deep into specific topics including business agility, SAFe for really big systems, Agile product management, and Lean portfolio management.

These are just five of the reasons why the European SAFe Summit has become one of the best-attended Agile conferences in Europe. This conference sold out last year, so don’t miss your chance to attend, learn, network, and grow.

Register now.

About Andrew Sales

Andrew Sales is a SAFe Program Consultant Trainer

Andrew Sales is a SAFe Program Consultant Trainer (SPCT) and a member of the Scaled Agile Framework team. He has been supporting organizations with their Agile transformations for the last 10 years and is a regular speaker at Agile conferences and contributor to the Agile community. Andrew previously led the Agile Services Practice across EMEA for CA Technologies (formerly Rally).

View all posts by Andrew Sales

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Have Fun During PI Planning

Read the Blog Post

A Framework, Not a Prescription – Scaled Agile Framwork

Posted on
A person putting up stickies on a board during an Agile planning

Now that SAFe® 5.0 is live, I wanted to take a minute­­ to reset the baseline on what exactly a framework is, what it isn’t, and what’s required to win with SAFe.

One of the most inspiring things I’ve experienced in working with SAFe is seeing the excitement and energy that it brings out in others. After learning in the classroom, many well-intentioned people run back to their organizations to ‘do the thing,’ but often forget to first understand the problem to be solved and the significance of the change ahead. Many proceed without first rooting themselves in what it is that they, and others, must do. Unfortunately, bypassing this step and failing to broadly communicate the vision can lead to many false starts.

In this post, I’ll explore patterns to consider for improved outcomes when using the Framework, offer some tips to apply tools found in SAFe and relate them to your context, and identify patterns to help avoid making Framework guardrails feel overly rigid.

The case for change

Change for the sake of change is rarely a successful undertaking. And change is hard—really hard. Consider any change you’ve tried to make in your life: a new fitness routine, a new diet.

Without a compelling case to make the change, many of us abandon these new habits before they’re integrated into our lifestyle (culture or lifestyle change is the result of changing; not a reason for change.)

Example: A 5 a.m. run, the second week of January, when it’s cold and you’re sore.

The result: Abandoned change.

Example: Out with coworkers at a pizza joint the second week of a new diet when your body is craving sugar/fat/salt.

The result: Abandoned change.

Example: The beginning of the second PI Planning when there’s no architectural runway, leaders can’t decide on priorities, managers are frustrated with understanding the new way of working, and teams are being pressured to just deliver something.

The result: Abandoned change.

I’m guessing you can probably relate to at least one of these scenarios. 

Now, reexamine the same scenarios with a clearly articulated “why” and consider how understanding the case for change may yield different outcomes.

Embracing a new fitness routine [BECAUSE] it’s difficult to keep up with the kids.

The result: Maybe that cold morning is a little more bearable.

 Adopting a new diet [BECAUSE] your current one has contributed to pre-diabetes.

The result: Amazing smells or not, that pizza is now a little easier to say no to.

 Adopting a new way of working [BECAUSE] your business is at risk of being disrupted by smaller, faster companies who are talking directly to your customers.

The result: Maybe we need to work a little harder to figure out our priorities.

 As John Kotter points out, many people underestimate the power of vision 10x. Before starting your journey toward business agility, take a moment to understand the need for change, share it broadly with the impacted parties, and keep the vision visible. 

Framework = toolbox

Allow me to be direct: The Scaled Agile Framework® (SAFe) is not prescriptive. It’s not intended to be a method to perpetuate command and control and it’s not an organizational structure. SAFe is intended to be a second-tier operating system that filters together the right people to solve a problem and gives them the focus and support they need to deliver the highest business value items in the shortest sustainable lead time.

If an organization chooses to use the Framework in a manner other than intended, then the result may feel rigid. Though, that has nothing to do with the Framework. SAFe is a toolbox containing proven methods and practices that help businesses solve many of the complex issues they face today. With that in mind, it’s up to the practitioners and leaders to understand their problems, understand the tools available, and determine the Leanest subset of tools needed to address those problems.

Businesses can be complex, and each operating environment is unique. No matter your starting point, it’s the right place for you and your organization. SAFe won’t solve all problems overnight but it will help drive the right conversations at the right time. What SAFe does is help you surface many underlying issues within the system, and as W. Edwards Deming so famously points out, “… only management can change the system.”

Scaled Agile Framework

Mindset. Values. Principles.

With so much flexibility built into the Framework, people often ask me if one decision or another aligns with SAFe. It’s important to remind yourself that the goal is to delight the customer by delivering high-quality value as quickly as possible—and to do the right thing. The best way to make the best decision in these scenarios is to refer back to the Lean Mindset, SAFe Core Values, and Lean-Agile Principles and ask yourself, “Does this decision move me closer to or further away from these points of reference?” If the decision aligns with the values/mindset/principles, it’s probably the right decision. 

The essential elements

The basics are the basics for a reason: they’re the minimum elements required for success in an undertaking, which in our case is scaling an Agile mindset in a complex organization. The basic element of SAFe is the need to bring together more than a few teams to deliver value and delight the customer. If you can accomplish this with one two/three/four team(s), then you probably don’t need SAFe. However, as organizations, architecture, and organizational challenges become more complex, the need to scale becomes apparent. To scale Agility to the team of teams for solution delivery, we must consider the essential competencies and elements.

Three core competencies

Team and Technical Agility

Team and Technical Agility describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and teams of Agile teams use to create high-quality solutions for their customers. Agile Product Delivery is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users. Lean-Agile Leadership describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential.

The elements of Essential SAFe

An Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and (where applicable) operates, one or more solutions in a value stream. A Continuous Delivery Pipeline describes the workflows, activities, and automation needed to consistently release value to end users. Customer Centricity is a mindset and a way of doing business that focuses on creating positive experiences, such as the customer journey, which takes buyers through the full set of products and services that the enterprise offers. Design Thinking is a customer-centric development process that creates desirable products that are profitable and sustainable throughout their lifecycle. Program Increment (PI) is a timebox in which an ART delivers incremental value. PIs are typically 8 – 12 weeks long, and the most common pattern for a PI is four development Iterations followed by one Innovation and Planning (IP) iteration. Iterations are fixed-length timeboxes that provide the development cadence for Agile teams building Features and components. Each iteration delivers a valuable increment of new functionality. Innovation and Planning (IP) Iteration provides teams with an opportunity to explore and innovate, dedicated time for planning, and learning through informal and formal channels. ScrumXP is a lightweight process for Agile Teams to continuously deliver value. ScrumXP uses the Scrum framework for project management and XP-derived quality practices. Team Kanban is a Lean method that helps teams facilitate the flow of value by visualizing workflow, establishing work in process (WIP) limits, measuring throughput, and continuously improving their process. Built-In Quality ensures that in every solution increment, teams (technical and non-technical) achieve high-quality goals and can readily adapt to change. DevOps is a mindset, culture, and set of technical practices. DevOps provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a system.

A state of perpetual change

With the significant additions that come with version 5.0 of the Framework, I ask that we all remain diligent along our learning journey. The Framework site offers an overview of the basics of many concepts to consider on the journey to business agility, but it isn’t a formula for assured success. SAFe courseware is intended to rapidly bring students to a new learning plateau and help each learner discover which areas of the Framework content they’re most interested in exploring deeper.

Pick a subject area, learn more, speak to other practitioners on the SAFe Community Platform, and think critically about how to best deploy SAFe tools to guide your organization and customers to a better place. As we discuss in the competency of developing a Continuous Learning Culture, the future belongs to those who learn the fastest.

 Scaled Agile will continue to investigate the latest trends in the post-digital economy, and provide recommendations, toolkits, and learning to help the great organizations of the world survive and thrive with new ways of working.

—Adam

About Adam Mattis

Adam Mattis headshot

Adam Mattis is a SAFe Program Consultant Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across a wide range of industries. He’s also an experienced transformation architect, engaging speaker, energetic trainer, and a regular contributor to the broader Lean-Agile and educational communities. Learn more about Adam at adammattis.com.

View all posts by Adam Mattis

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: What in the World Is SAFe?

Read the Blog Post