The Scrum Master Exchange Program: A Twist on Professional Development

Scrum Master Exchange

My career path shifted at the beginning of 2021 when I became a full-time scrum master. I knew right away that to be the best scrum master I could be, I’d need to do continuous professional development. 

One disadvantage I noticed right away was that I‘d only seen Agile, Scrum, and SAFe® in action in the context of one, unique, midsize organization. To be more well-rounded in my abilities to lead and coach, I needed to experience companies of different sizes, within different industries, and with a different company culture to see how these principles and practices played out—as well as how their SAFe transformation took shape. The more that I saw, the less I would view my company, my teams’, and my own routines as the only perspective. The more I saw, the more I could view innovation as possible because it worked over there.

That’s when the idea came to me to be my own hero and think of something tailored to my professional development needs. With support from my leaders and peers, I created a Scrum Master Exchange Program. I invited interested scrum masters from Scaled Agile and from Travelport, and we paired and connected. From there, pairs self-organized and scheduled several sessions. 

  • Introduction—in this session, pairs introduced themselves and shared their professional background, strengths, weaknesses, and goals. They also talked about their current context: their company, their teams, a typical day/iteration, current conflicts, and recent successes. 
  • Shadow—in these sessions, one scrum master silently sat in on the other’s scrum events or even parts of their ART’s PI planning events. The silent scrum master noted group dynamics, facilitation techniques, or anything interesting.
  • Debrief—pairs scheduled debrief seasons soon after shadow sessions to share observations, relay positive and constructive feedback, and ask questions.

We closed the program with a retrospective for all participants and a summary email to participants and their people managers. 

What I Learned

So, how did it go? When we came together to review the program and its benefits, we all agreed that the new perspectives, experiences, and what we learned were things we deeply valued. Connecting with our partners and problem solving together was empowering and often resulted in us taking action toward solving our challenges. 

For me personally, as a new scrum master, I gained confidence in my knowledge and abilities. While my partner was extremely experienced, I could empathize with her problems. And I could even inspire her to consider something new, which made me feel competent and affirmed.

I took away a new mindset, now pursuing more simple, effective, and tried-and-true methods, focusing on the purpose. For example, I would get really creative with my iteration retrospectives, but they could be time-consuming to ideate and build, and the results easily became disorganized. My partner had a very simple, organized, centrally located method and kept things predictable. Though mine still isn’t perfect, I continue to take steps to bring my style a bit closer to hers (I can’t abandon all flair!).

Last but not least, I was further reminded that my professional development, my teams’ development, and my company’s development is a journey. I know what you’re thinking: “How cliché.” But the truth is, you can’t do everything, so you might as well do something. By maintaining a relentless improvement mindset and taking small steps, both you and your teams can get better. 

Key Takeaways

Was the exchange program perfect? No. But we all met someone new in our same role and got a peek behind the curtain at their respective organizations. And, if we decide to implement the program again, we know how to improve it. I’m proud of the fact that I noticed a hole in my professional development and took action, learned a ton, and brought some of my peers with me along the way. I’d call that a successful experiment. 

I’d strongly encourage you to try out an exchange in whatever role you have. Here’s how: 

  1. Float the idea with your peers to find people to join you.
  2. Reach out to your networks, your coworkers’ networks, and your company’s networks to select a potential organization with which to work.
  3. Pitch the idea, gain buy-in, and connect with legal for any necessary paperwork.
  4. Finalize the participant lists, pair them up, and send them off.
  5. Don’t forget to run a retro and spot ways to improve.

 Let us know how it goes!

About Emma Ropski

Emma is a Certified SAFe 5 Program Consultant and scrum master

Emma is a Certified SAFe 5 Program Consultant and scrum master at Scaled Agile, Inc. As a lifelong learner and teacher, she loves to illustrate, clarify, and simplify to keep all teammates and SAFe students engaged. Connect with Emma on LinkedIn.

Share:

Back to: All Blog Posts

Next: Aligning Global Teams Through Agile Program Management: A Case Study

How to Scale Up the Circular Economy

This blog post will illustrate, with practical examples, how the principles and practices of the Scaled Agile Framework® (SAFe®) can contribute to scaling up the circular economy. 

The circular economy offers opportunities for better growth through an economic model that is resilient, distributed, diverse, and inclusive. It tackles the root causes of global challenges such as climate change, biodiversity loss, and pollution, creating an economy in which nothing becomes waste, and which is regenerative by design.

Many enterprises are committed to making their products eco-friendlier and participating in global coalitions such as The Plastics Pack. Nevertheless, due to the lack of global standards or lack of dialogue and collaboration, they could create fragmented, small-scale, and sub-optimal solutions. For example, an enterprise might design a product that contains recyclable materials, is built with mono-material components, and is easy to disassemble. Still, it would only maximize its recycling value when embedded in a functioning collection system and treated in proper recycling facilities.

What Is the Solution, Then?

Circularity is a property of a system and not of individual products. It depends on how different actors, products, and information interact with each other. Improving the whole system would require that a group of loosely coupled actors combine their business models to achieve a better collective outcome. The proposed solution is a virtual organization that aligns the strategy and execution of all the stakeholders creating a solution ecosystem.

Let’s look at one example. I will illustrate a management framework to improve the packaging plastics system shown below.

Scale Up the Circular Economy

Applying SAFe Principles to the Circular Economy

SAFe principle #10, Organize around value, recommends creating a virtual organization that would maximize the flow of value. It involves eliminating silos and barriers for collaboration, including the people, the processes, and the tools, from all relevant stakeholders that are trying to achieve the same outcome.

This organization would be called a solution ecosystem, and its goal will be to implement the desired changes. Following SAFe principle #2, Apply systems thinking, the solution ecosystem would include all the actors involved in or impacted by the flow of packaging plastics, from business, government, scientists, and NGOs to end-user communities, including all the necessary activities and information flows required. Decisions would be made collaboratively, iteratively, and based on science-based targets.

The objective of the solution ecosystem would be to deliver a series of interventions to improve the flow of plastics iteratively. The teams would validate each intervention hypothesis through a series of minimum viable products following a roadmap. An intervention example could be, “to get the top 20 manufacturers of packaging plastics to commit to plastic packaging that’s 100% reusable, recyclable, or compostable by 2025,” while the desired outcome would be “to reduce packaging plastics flowing into the ocean by 50%.”

The solution ecosystem comprises small, long-standing, cross-stakeholder, and cross-functional teams or teams of teams dedicated to addressing specific outcomes. They will also have access to part-time specialized resources and count on all the necessary skills to deliver value independently of other teams.

The solution ecosystem could be coordinated top-down, from organizations such as the World Economic Forum, or led by a single enterprise coordinating with all the stakeholders impacted by its products. This organization could reach out vertically to all actors along the supply chain, such as those in logistics, packaging, and wholesale, horizontally to competitors, or circularly to all stakeholders impacted. 

Aligning Strategy to Execution

The solution ecosystem is likely to be composed of many people and organizations. To align strategy and execution, SAFe proposes to create a golden thread. From a single and shared vision to strategic themes to a common backlog of interventions to hold and prioritize all the interventions that will realize those themes.

The overarching vision of the New Plastics Economy is that plastics never become waste. Instead, they re-enter the economy as valuable technical or biological nutrients, creating an effective after-use plastics economy, drastically reducing the leakage of plastics into natural systems, and decoupling plastics from fossil feedstocks.

Scale Up the Circular Economy

Strategic themes are the way to achieve that vision or areas of investment. They are a way to group and classify Interventions. The solution ecosystem’s scientific community would express them in objectives and key results (OKRs). Thus, providing a qualitative and quantitative measurement to evaluate progress and success. An example could be:

Objective: Drastically reduce leakage of plastics into natural systems.

  • Key result 1: Improve after-use infrastructure in high-leakage countries by x% 
  • Key result 2: Increase the economic attractiveness of keeping materials in the system
  • Key result 3: Increase investments in efforts related to substances of concern by x %

The teams would strive to accomplish the strategic themes by implementing a series of interventions.  The solution ecosystem’s backlog is the prioritized list of interventions to be done. For example, it might look like this:

  1. Bio-benign materials
  2. Reversible adhesives 
  3. Super-polymer
  4. Plastics toolkit for policymakers 
  5. Bid data service to track the flow of dangerous chemicals
  6. Food delivery containers as a service

Collaborative Decision-making Process

SAFe recommends using Participatory Budgeting (PB) as a tool for budget allocation across the same enterprise business units. We could expand PB for multi-stakeholder decision-making, as many municipalities use it, gathering all the stakeholders’ voices. All the stakeholders impacted would be heard, voice their concerns, choose their priorities, and learn about other stakeholders’ concerns. The PB process should be done periodically to create a rolling wave agreed plan.

Creating a Balanced Portfolio

To maintain a well-balanced portfolio, SAFe proposes several budget guardrails:

  • Capacity allocation: This technique classifies interventions into different types and allocates a percentage of the available capacity to each kind, such as building the basic science, writing communications material for end-users, or drafting policy documents. Every three months, we can decide the percentage allocation to each type, keeping the desired balance across all categories.
  • Investment horizons: Classifying interventions by their impact timeframe allows leadership to maintain the right balance between the immediate, short, and long term. Quick wins are needed to win the hearts and minds of the naysayers, while the more difficult things usually take longer.
  • Epic approval: Decentralizing decision making is fundamental to reduce time-to-market and to improve flow. Nevertheless, substantial initiatives that impact multiple stakeholders need to go through an approval process based on a short business case. 

Project to Product

The traditional project approach would have required well-defined Interventions with fixed scope, fixed budget, and a fixed timeframe, such as building a clearly defined database of biomaterials at the cost of £2m over one year. One major drawback of this approach is that the success criteria of the intervention usually focus more on staying within these artificial constraints rather than on achieving the desired outcome of increasing the percentage of biomaterials used in packaging plastics by x%. Another problem is that designs and plans must be agreed upon upfront to obtain funding and approval. At that moment is when we know the least about the problem and the solution. Hence, it becomes harder to pivot later if needed.

The book Project to Product proposes a product approach, where funding is associated with long-standing teams working on a set of interventions related to the desired outcome. They would iteratively validate hypotheses and measure progress irrespective of the validity of their initial plans and assumptions. Products must be launched and maintained during their life cycle and have multiple target users with evolving needs. 

For instance, the budget would be related to a product called ‘biomaterials for packaging,’ including research, product launch, product support in life, and end-of-life activities, rather than related to a project to launch a new packaging material.

Timeboxing

SAFe principle #1, Take an economic view, proposes that we work incrementally and iteratively. Working in small timeboxes and on small pieces of independently valuable work would allow us to obtain the best economic outcome. We will get quick feedback; the value will get accumulated over time, and it will enable us to test our hypothesis and pivot quickly if needed.

SAFe principle #7, Cadence and synchronization, promotes that all teams involved in the solution ecosystem get together every three months to collaboratively plan the work for the next three months. This recurrent process helps evaluate progress toward the shared outcome, manage cross-team dependencies, and facilitate cross-team collaboration to create a stable and predictable rhythm of key events. 

Every three months, all teams demonstrate their accomplishments to evaluate progress objectively. They would get together to reflect on how they deliver value and look for opportunities to improve the process.

Epic Owner

The Epic Owner is a new role that would work at the solution ecosystem level to track and shepherd the intervention through its life cycle and across all the teams involved. In our example, the Epic Owner for the biomaterials database would be accountable to define the scope, building the short business case, getting it approved, building the teams across all stakeholders, tracking progress, being a consultant to the delivery teams, and evaluating whether they are meeting the desired outcome. It is a role, not a title. Hence, it might be fulfilled by a group of people.

Transparency

Transparency and visualization of all the work and all the dependencies by everyone are key. Kanban boards would allow us to see every intervention’s status to match demand with available capacity. A dependency board would show when each intervention will be delivered and its dependencies with other teams.

Decentralized Decision-making

No amount of central planning will be enough at this scale. To enable decentralized decision-making, we need to create a framework that provides organizational clarity and technical competence. This would allow individual teams to make decisions independently with the confidence that those will be good decisions. An example could be that a team can decide to increase the cost of the solution up to £1,000 to produce an additional reduction on the amount of plastics leakage into the ocean, as long as there is no impact on any of the other planetary boundaries.

References and Sources of Inspiration

Several reports are calling for organizations like the proposed solution ecosystem that could lead a multi-stakeholder systemic change:

  • The Metabolic Institute proposed that The Netherlands implements a regional ecosystem approach to scale up circular economy innovation.
  • The Ellen MacArthur Foundation calls for a global, independent collaboration initiative that brings together all actors across the value chain from consumer goods companies, plastic packaging producers, plastics manufacturers to cities, businesses involved in the collection, sorting and reprocessing, policymakers, and NGOs.
  • J. Konietzko writes, “Ecosystem innovation aims at changing how actors relate to each other and how they interact to achieve the desired outcome… circular products and services often maximize their circularity in conjunction with other assets. A circular ecosystem perspective thus goes beyond the question, what is our value proposition? Instead, it asks, how does our offering complement other products and services that together can provide a superior and circular ecosystem value proposition?”
  • D. Meadow, in her book Thinking in Systems, says, “You can’t predict a system, but you can dance with it.” Hence, do not design a solution upfront at the enterprise level, expecting the whole ecosystem to react as you hoped. Instead, implement a management framework that allows you to work iteratively at the system level, which we call the solution ecosystem; listen to the feedback, and react accordingly. 

Conclusion

In this blog post, I proposed a management framework, adapted from the Scaled Agile Framework, to manage a multi-stakeholder ecosystem to scale up solutions for the circular economy. At this stage, these are ideas extrapolated from my experience in business agility transformations and my readings into the circular economy. Please get in touch with me via LinkedIn to explore these ideas further, or if you have a concrete initiative you would like to apply them to.

About Diego Groiso

Diego Groiso Scaled Agile Partner

As a Principal Consultant at Radtac, a Scaled Agile Partner, Diego supports companies in their Business Agility journeys as an Enterprise Agile Coach, Trainer, and Release Train Engineer. Recently, he has transformed the whole infrastructure department of a global utility company, as well as launched and coached several Agile Release Trains within the Digital Transformation Programme in a global telecom company. He has a passion for the circular economy as one of the solutions to climate change. Connect with Diego on LinkedIn.

Share:

Back to: All Blog Posts

Next: Aligning Global Teams Through Agile Program Management: A Case Study

Can SAFe Make the World a Better Place?

Recently, someone asked me to explain the benefits of SAFe® over other Agile frameworks. Before I answer, I want to point out that I am not opposed to other scaling frameworks (we don’t do that!). What I can do, however, is speak from my own experience and give you some insight into why I choose to specialise in SAFe.

One of the best books I read last year was Switch: How to change things when change is hard, by Chip and Dan Heath. The book talks about communicating a vision and uses a great analogy of the elephant and the rider. The rider represents the rational self, and the elephant the emotional self. If the rational brain interests you, I suggest you look at the customer stories at the Scaled Agile website. There you can explore a treasure trove of case studies based on data.

I’m going to focus on the elephant. A common question in SAFe classes is where the data sits behind the statistic, “30 percent increase in employee engagement.” I usually answer this question by telling a true story about a Programme Manager I worked with called Steve (his real name isn’t Steve). 

Steve worked in a large organisation for 20 years. Over the years, he honed his craft by emulating those who had gone before him. He worked his way up the project management ladder and became highly respected by all who had the pleasure of working with him. There was just one problem, Steve had learned that the best way for his projects to succeed was to be at the centre of everything. Every decision went through him, and every status report had to be filled out precisely the way he did it; if not, you would have to do it again. Now, this all sounds sensible: Steve knew what his stakeholders needed to know, and he made sure that they had the information they needed to sail through his milestones with minimal fuss. There was one fly in the ointment: Steve had to work 60 hours a week to maintain control.

The organisation that Steve works in decided to go SAFe and identified his programme as an ideal candidate to launch an ART. Steve was willing to try but was sceptical about a new approach. We followed the SAFe Implementation Roadmap, trained everyone and got ready for PI planning. This is the point in our story when everything changed.

In the first PI planning, the room’s energy was unlike anything seen before. Because everyone who needed to be there was in the same room, the teams managed to unblock a capability in the first hour of the first team breakout that had stumped everyone for three months. The momentum continued to build from there; the ART launch was a tremendous success.

To understand why I think SAFe is so brilliant, we need to fast forward a few PIs. It was the summer season, and Steve took some time off to relax and soak up the sun. For the first time in years, Steve was not on his phone. He was not checking emails. He relaxed. When I caught up with him shortly after his holiday, he said, “Thanks to SAFe, I’ve got my life back.” Steve was no longer working crazy hours to stay in control. He had let go of many day-to-day decisions. He trusted the teams to make the calls on the things they were close to so that he could focus on the strategy.

I believe that SAFe is so fantastic because it gives us just the right balance of guidance and flexibility. The 10 SAFe Principles help us put the changes in behaviour into practice. As a coach, they are at the front of my mind whenever I’m thinking about implementing SAFe. And for people like Steve, they help put the mindset into practice and apply it to their own context. We can’t be overly prescriptive; every context is different. 

Steve’s story is far from unique; I’ve seen many people’s lives change for the better as they embrace a new way of working. That is why I do what I do. Business benefits are essential, the ability to respond to changes in the market is critical, but I’m all about the people. 

It’s no accident that the first value of the Agile Manifesto is individuals and interactions over processes and tools, or that the first pillar of the SAFe House of Lean is respect for people and culture. What could be more important than making the world a better place for people to work? What could be more valuable than improving the happiness and wellbeing of our people?

So, can SAFe make the world a better place? I believe so!

About Tim

Tim-  SPCT

Tim is an experienced SPCT who has been working in Agile and software for the last 12 years. Over the years, Tim has worked in a variety of industries such as telecom, pharma, and aviation, leading large transformation initiatives. Connect with Tim on LinkedIn.

Everything You Wanted to Know About SAFe® Enterprise (But Were Afraid to Ask)

When you think of the name “Enterprise,” what comes to mind? Space shuttles? Aircraft carriers? If you’re like me, you might think about Star Trek. From the OG Bill Shatner through Chris Pine’s nuevo-style Kirk, the debates about who embodies the future’s proper swagger could be endless. But the adventure, the collaboration, and the problem-solving are universal. The Enterprise gets it done. 

Here in the virtual halls of Scaled Agile, we’ve figured out the best way to ensure a successful and sustained SAFe transformation—and it has the “Enterprise” name on it as well.

Since we launched SAFe® Enterprise at the Global SAFe® Summit user conference in October 2020, there’s been a lot of buzz in the Community forums: “What’s this hype around SAFe Enterprise?” So, let’s break down some of the common questions I get about SAFe Enterprise

Is SAFe Enterprise Something Entirely New? 

To use a long and complex word: No. But what is new is that we took our world-class SAFe training and added what companies need to have a successful SAFe transformation. Don’t worry, SAFe Enterprise builds on everything SAFe is known for: A robust training curriculum to empower and enable teams to move toward business agility. An industry-recognized certification program to demonstrate deep knowledge and understanding of SAFe concepts. A giant, 800,000+ (and growing daily) community of SAFe-trained professionals who are helping organizations achieve great outcomes. But with SAFe Enterprise, training is just the beginning. 

So is SAFe Enterprise Just a Way to Get Unlimited Training? 

SAFe Enterprise is the best solution for organizations to learn, adopt, practice, and sustain SAFe. Building on the proven foundation of classroom training, This provides the tools and resources organizations need to extend that learning beyond the classroom and empower teams to bring the knowledge they learn in class back to their day-to-day work. (I’ll dig into some of these fantastic capabilities in future blog posts.)

Most importantly, the system is purpose-built for SAFe. Collaborate together as a team, improve your own skills, or connect and learn from others in the community. This is the definitive one-stop package for the entire organization to learn, implement, and sustain business agility.

Is There Any Difference Between Certified SAFe Membership and SAFe Enterprise? 

Absolutely. SAFe Enterprise is not for individuals, or even for your team. It’s for your entire organization, with tools to help manage access for all members within the account. Certified SAFe members have individual access to the SAFe® Community Platform and tools to help them with their day-to-day job. But SAFe Enterprise is a solution built for the entire organization, so teams across the organization can simultaneously build on the benefits of SAFe day-to-day.

We Love Our Scaled Agile Partners. How Does SAFe Enterprise Help Our Partners Train and Coach? 

Partners are essential for successful SAFe transformations: they’re trusted teachers, guides, and coaches that help organizations move from where they’ve been to where they’re going. SAFe Enterprise enables your trusted partner to do two big things. First, it removes individual budget barriers to training by including unlimited licensing and certification renewals for the majority of roles within the organization. Second, it provides instant, organization-wide access to e-learning, helpful videos, and tools that Scaled Agile Partner coaches and consultants can help teams use from day one. In addition, SAFe Platform partners provide enterprise-grade solutions for ALM and project management software that work seamlessly alongside SAFe Enterprise. 

So, this is our Enterprise—SAFe Enterprise: helping organizations across the globe be better at what they do, every day. 

If you think this might be right for your organization, contact your Scaled Agile Partner or get in touch with us directly and we can help you get started.

About Morgan

Morgan - SAFe® Enterprise

Morgan is on the marketing team at Scaled Agile and has nearly 20 years of experience leading and building both product and marketing teams. Based outside of Boulder, Colorado, he enjoys the area’s excellent food and outdoor lifestyle.

Share:

Back to: All Blog Posts

Next: Honest Assessments Achieve Real Insights

Three Lessons I Learned in My First Year as a Product Owner

My First Year as a Product Owner

I had managed marketing teams before, but being a product owner (PO) of an Agile marketing team was a completely new concept. As a team member, I was fortunate to spend a year watching POs do the job, which gave me a leg up. But I never really appreciated the intricacy of the position until I became one. Looking back at a year in the role, here are three key lessons I’ve taken from this experience.

The Scrum Master Is a PO’s Best Friend

Stop trying to do it all by yourself. You can’t, and you don’t have to. The scrum master is your co-leader. They don’t just run retros; they’re your sounding board and partner.  

Consider this: scrum masters spend their entire day thinking about how to support the team. Not the customer, not the executives—the team. So, listen to them. When they give you constructive criticism, listen. If they give you advice, listen. Scrum masters are often the ones at the back of the room watching everyone’s body language and unspoken communication while you’re busy thinking about the stories and features. They can catch things you don’t, so listen to them.

Planning Is Hard but Don’t Give Up

A year ago, you would find me crying after each iteration planning. Somehow we would start with 270 percent of capacity and be lucky if we got down to 170 percent—almost twice as much work planned than we could ever physically complete. If our planned capacity was ridiculous, our predictability was nonexistent. One iteration, we’d complete 120 percent, the next 50 percent—who knew what you were going to get from us.  

But we stuck with it.

We invested in iteration planning and backlog refinement. We went back to basics, agreeing on the definition of a “1” so we could do relative sizing. We started planning poker, where everyone on the team had a say in how to size stories, even if they personally were not doing the work.  And we started getting more serious and explicit about what we could and couldn’t accomplish inside two weeks.

iteration planning

A year later, I beam with pride. We’re a predictable and high-performing team. When we tell another team we can deliver something within an iteration; it’s the truth. Not a gut check, and employees don’t have to work insane hours to make it happen.

Pro Tip: If you’re struggling with iteration planning, I strongly recommend downloading the Iteration Planning Facilitator Checklist on the SAFe Community Platform. There’s also a good instructional video on the Team Events page.

PI Planning Is Not A Drill

I usually start thinking about PI Planning in iteration four. I don’t have features, I don’t know what the pivots will be, but I’m already thinking about what conversations I have to have to get my team ready. I’ve already got my finger in the air to sense the direction of the proverbial wind. My scrum master and I spend a lot of time thinking about preparing the team for PI Planning, creating space for exploration, and making sure we discuss every possible dependency, so there aren’t surprises later.

Virtual PI Planning offers another level of complexity. It’s absolutely critical that I have everything organized for my team and me, documented, and ready to go before we log in. The team knows where to find information, what the marketing objectives are, and what teams we need to sync with to plan our work.

Are you a PO? What lessons have you learned? What do you wish you knew when you started? Join the conversation in the SAFe Product Owners/Managers Forum on the SAFe Community Platform.

About Hannah Bink

Hannah Bink heads the Marketing Success team at Scaled Agile

Hannah Bink heads the Marketing Success team at Scaled Agile. She has nearly 15 years of B2B marketing experience and studied business at Pennsylvania State University. Prior to Scaled Agile, Hannah spent the majority of her career in telecommunications and healthcare sectors, running global marketing divisions. She is also author of the “Musings of a Marketeer” blog, and lives in Denver, Colorado.

View all posts by Hannah Bink

Share:

Back to: All Blog Posts

Next: How Vendors Can Apply Customer Centricity When Organizing Around Value

How Vendors Can Apply Customer Centricity When Organizing Around Value

Customer Centricity

In this post, we look at how a B2B vendor should organize around value when building products that are used to support its customer’s business operations. A common example might be a vendor building a CRM system. 

Organizing Around Value

Lots of organizations are organized around functional silos—such as business, system engineering, hardware, software, testing/QA, and operations. These structures exist because they support specialization and allow organizations to grow and manage their people effectively. It’s why so many organizations are set up in this way. And many organizations persist in this siloed structure even when they start their journey toward business agility.

For example, they create Agile teams that map to specialized components or subsystems. Similarly, they create Agile Release Trains around entire departments or functions. From a change management perspective, it’s easier to keep the current structure and apply Agile ways of working on top of it. But value doesn’t flow in silos. In many cases, these so-called Agile teams or teams of teams struggle to deliver valuable increments because what’s valuable requires collaboration across the silos. Additionally, teams struggle to see how their work builds up to something valuable for the customer. 

Business agility and digital transformation are all about speed of learning and value creation in the face of a dynamic changing environment. The classic organizational structure isn’t optimized for this speed, which is why SAFe® introduces the value stream network as part of a dual operating system that runs parallel to the organizational hierarchy.

Customer Centricity
The value stream network within a dual operating system.

Development value streams (DVDs) are the organizational construct used by SAFe to create this value stream network. DVDs are where the essential activities of defining, implementing, and supporting innovative, digitally enabled solutions occur. Defined correctly, DVDs are able to deliver valuable business solutions on their own with minimal dependencies on other parts of the business.

Alongside the DVDs are Operational Value Streams (OVSs) which describe the steps needed to deliver value to the organization’s customers. Examples might include providing a consumer loan or provisioning a software product. With this in mind, the DVS has one purpose: to create profitable OVSs. They do this either by creating the systems that the OVS relies on to operate effectively or by building the products that the OVS sells. With this in mind, understanding how the work is done in the OVSs helps us understand what value looks like, how it flows from demand to delivery in our context, and how we might organize our DVDs to support this.

What’s the Right Approach to Defining Operational Value Streams?

Identifying the OVS is a relatively straightforward exercise for a technology/development organization trying to organize effectively around the value that the wider organization is delivering to customers. People supporting systems that are used when providing these services (digital or physical) can easily apply customer-centric thinking and identify an OVS oriented around the needs of the real external customer.

fulfillment OVS
Example of a fulfillment OVS.

It gets tougher to map an OVS when you’re a vendor selling your product/solution for use as part of another organization’s operational activities. A great example is an independent software vendor (ISV). Other examples include vendors building and selling cyber-physical systems such as medical devices and manufacturing equipment. 

Consider vendor ACME Corp, which provides banks and financial institutions with banking systems. ACME Corp is building an AI-powered loan underwriting system that will fit into their banking systems portfolio. What OVS should ACME Corp model when considering how it might organize around value?

Many SAFe practitioners would suggest that ACME Corp model an OVS that focuses on how it would market, sell, and operate its solution.

Customer Centricity
Example of an OVS that follows the software product buyer journey.

Vendor IT folks supporting systems like CRM and ERP find it a useful way to model the business process they’re supporting. With this OVS in mind, they can make sure they organize around the whole buyer journey. And they can apply systems thinking to explore what features to introduce to the systems supporting this process.

The problem with this approach is that this OVS is mainly from the vendor and buyer journey perspectives. It doesn’t provide any information on how the solution will be used or the kind of work that it will support. An alternative approach is to use the real customer’s experience/journey as the OVS. Basically, take the same perspective that an internal technology organization would when building systems for these customers.

Customer Centricity
Example of a vendor applying customer-centric OVS.

Both the buyer journey OVS and customer-centric journey OVS exist. The question is: which of them is more useful to focus on? Remember that we map OVSs in order to build a hypothesis around what’s an effective DVS. In this example, both OVS perspectives can be useful. 

The customer-centric fulfilment OVS focusing on the solution context within which the ISVs product lives are the perspective that product development/engineering should focus on—this is where the systems/products/solutions that they create exist. This perspective would be more relevant to people building the products the vendor is selling because it would get them closer to their customers. It would also help them apply systems thinking to which features can really support generating value for these customers and for the enterprise serving these customers.

Customer Centricity OVS

Emphasize Customer Centricity as Part of Value Stream Identification

The example above illustrates why vendors can find it daunting to figure out which OVS to focus on. Going down the software product OVS perspective often leads to confusion and lack of guidance because it’s disconnected from how the products are used and from the solution context. A common move vendors make at this point is to fall back to organizing around products. Being able to explore, build, deploy, release, and operate/maintain a product can be a significant improvement for some organizations.

DVS
Example of a DVS oriented around the different systems/products, plus dependencies.

The problem with this structure is that it still has silos. And once we look at the value the vendor is trying to create, we might see a lot of dependencies between these silos. The management challenge is to connect the right silos—those that need to collaborate to deliver the value that the organization’s strategy is pointing toward. 

Leveraging customer centricity using the customer’s fulfilment OVS can help the vendor transcend product silos and maximize the value created by their product portfolio. More vendors we work with that started with ARTs and DVDs oriented around products find themselves with heavy coordination overhead across different DVDs and ARTs when executing on strategic themes and portfolio initiatives. 

Going back to our AI-powered underwriting product actually supports multiple steps in the customer-centric OVS, and requires new features across a range of the vendor’s products. Maximizing the value of AI-powered underwriting requires collaboration and coordination with the groups developing these products. If all of these different products are built by different DVSs, this coordination will be slow and painful. If the vendor organizes around value and brings the right people with the ability to get AI-powered underwriting integrated into the different products, time-to-market and quality will be improved. People would also feel more motivated and engaged since they’re very focused and effective. 

Using a customer-centric OVS is key to understanding your real solution’s context. This can enable you to organize effectively to minimize dependencies and enable collaborations that streamline the customer journey. Which is essentially the goal of most products—to help a business better serve its customers.

Customer Centricity OVS
Example of a vendor creating a DVS modeled around a customer-centric OVS.

When a DVS is created to support a customer-centric OVS, the organization can use techniques including value stream mapping and design thinking to innovate “in the Gemba—where the real value flows.” When this DVS includes everyone needed to explore, build, deploy, and support solutions that cut across the customer-centric OVS, we’ve truly created a network operating system that’s organized around value. And we’ve taken a huge step toward enabling real business agility. 

Join our webinar on June 9, 2021 with SAFe Fellow Andrew Sales. You’ll learn tactical advice and tips to identify operational and development value streams that help optimize business outcomes. We hope to see you there!

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

Next: Winning the Customer with Experience Architecture

Winning the Customer with Experience Architecture

 Experience Architecture

As the post-digital economy begins to boom and the worlds of business process and technology come together, it’s time to think about how we optimize the whole from a unified, customer-centric perspective. Some organizations have begun to master the idea of experience architecture, whereas others are just beginning.

During my years consulting, I’ve had the opportunity to work with complex system architecture. Such as the APIs and data structures across multiple federal agencies that manage annual earnings and death records for every person in the United States. I’ve also experienced complex business architectures responsible for moving passengers, aircraft, and cargo around the world in a safe and predictable manner.

What was obvious to me in these and other scenarios was that there was no way we could treat the disciplines of business architecture and technical architecture as independent variables. Especially if these organizations hoped to keep up with the speed of innovation. In early experiments, I hypothesized that by pairing business architects with their peer application architects, we could better design experiments to achieve business outcomes that were efficient and technically sound. My hypothesis was partially proven. There were still missing pieces of the equation.

In later experiments, I treated the various architects in the value stream as an Agile team composed of all architectural perspectives that we needed to deliver the solution. Those perspectives included business architecture, application architecture, systems architecture, data architecture, information security, and even Lean Six Sigma Black Belts to help keep the group focused on flow efficiency. That experiment had some cool outcomes, though I had come to realize one obvious hole: the lack of consideration for the people in the system. We needed a different skill set. We needed experience in architecture.

Curated Experiences and Powerful Moments

In their book The Power of Moments, Chip and Dan Heath give many examples of how people remember exceptionally good and exceptionally poor experiences. The authors illustrate how average experiences are largely forgettable. Conversely, experiences that are repeated merge together so that customers develop a general perception of the experiences, but don’t remember any experience in particular.

My family visits Disney. A lot.

 Experience Architecture

Before I met my wife, I’d been to Disney World twice in my life. Once when I was eight and again as a teenager. I have fond memories of each trip and can remember specific moments. These were positive experiences and here’s why.

Since having met my wife, I’ve been to Disney an average of twice annually and as many as four times in a single year. Each of those experiences has been positive, but I can’t articulate why. I know that I enjoy Animal Kingdom and the Avatar ride in Pandora. I know that the Magic Kingdom gives me anxiety and that you can get prosecco at Epcot. Unlike the trips of my youth which are memorable, not a single visit as an adult stands out. The experiences have merged.

My Disney experience is what most customers experience as they interact with our value streams. The customer will form a general feeling and only talk about the experience: if it was exceptionally good or exceptionally bad.

Need proof? Check out the reviews on Amazon or Google. You’re likely to see mostly very positive and very negative reviews without much in the middle. There is power in moments. The moments are what we remember and they can be curated when an organization makes investments in experience architecture.

Map Value Streams and Understand the Experience

Similar to the steps of value stream identification and business architecture, the first step in articulating a customer experience is to map the operational value stream. With alignment on how the business operates, the next step in understanding the customer experience is to visualize the technology that supports the operation and the development value streams that maintain the technology. Speaking of value streams, check out this cool webinar where I talk about them with Danny Presten.

With the value streams mapped, the next step is to embark on a journey to optimize the whole by eliminating technical and operational debt. With the help of business architecture, we can leverage the time focused on improvement to begin identifying opportunities for large-scale improvement in operational throughput. Additionally, the organization can begin investing in capability modeling with the goal of running more experiments for strategy implementation, faster.

With the operational value stream mapped, the underlying architecture understood, and a commitment made to relentless improvement, we can now begin exploring the customer experience.

Map the Experience

Now that we’re ready to map the customer experience, we begin by seeking to better understand the customer. SAFe® advocates using design thinking as a framework for customer centricity to best use personas, empathy maps, and experience maps. The art of experience mapping follows similar best practices used in other forms of value stream mapping. The distinct difference is that we engage with customers to understand their journey from their perspective.

Below is an example of an experience map that depicts the experience of an online public learner in the SAFe ecosystem. At the top, you’ll notice the phases of the customer journey, followed by the operational value stream. We continue by seeking to understand the customer’s goal within each component of the value stream, the touchpoints that Scaled Agile has with the customer, and finally, the customer’s happiness after having completed the operational component.

Similar to other types of value stream mapping, with the customer experience articulated, we can now start on a path to relentlessly improve the customer experience and curate memorable moments.

 Experience Architecture

Curate Unforgettable Moments

The Heath brothers explain the power of moments as a key theme in their book. For me, the true power of moments became evident when I purchased a new home in July of 2020. Veterans United Home Loans has made a significant investment in its customer experience and has taken advantage of the power of moments. The proof? The fact that nearly a year later I am blogging about my mortgage experience.

If you’ve ever bought a home, you can probably empathize when I say that it’s a stressful experience. In any mortgage transaction there are two particularly stressful phases for future homeowners: approval, and more notably, underwriting. Through their work in experience mapping, Veterans United was able to recognize this and curate moments to help ease the stress a little. When I received the approval for my home, my mortgage broker, Molly (do you remember the name of your mortgage broker?), sent me a pair of Veterans United socks.

 Experience Architecture

Yes, socks. They weren’t the best quality, they were kind of corny, but they made me smile and I’m still talking about them. Moment curated. 

When I closed underwriting, the curated moment was a little more personal. Molly had done her homework and knew that I liked to barbecue. So, she sent me a nice set of outdoor cooking utensils. As you sit there and ponder the ROI on socks and cooking tools, remember that you now know about Molly and Veterans United. ROI achieved. 

What low-cost, high-impact moments can you curate for your customers? How can you turn an otherwise forgettable experience into something that people remember for years to come? These actions are key to winning in the post-digital economy. Consumers want to know your organization is human. They want to know that you care. What can you do to help make that connection?

Experience Architecture: Conclusion

Success in the post-digital economy will require business agility and a clear focus on the customer. Experience architecture is something organizations should employ to better understand the customer so they can release on demand, as determined by the market and customer.

If you’re an experienced experience architect, consider sharing your stories in our General SAFe Discussion Group on the SAFe Community Platform. To learn more about working with varying architectural disciplines, while maximizing the amount of work not done, and embracing a just enough, just-in-time approach, check out these architectural runway articles.

About Adam Mattis

Adam Mattis is a SAFe Program Consultant Trainer (SPCT)

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

Next: Aligning Global Teams Through Agile Program Management: A Case Study

Measuring Agile Maturity with Assessments

Stephen Gristock is a PMO Leader and Lean Agile Advisory Consultant for Eliassen Group, a Scaled Agile Partner. In this blog, he explores both the rationale and potential approaches for assessing levels of Agility within an organization.

A Quick Preamble

Measuring Agile Maturity with Assessments

For every organization that embarks upon it, the road to Agile adoption can be long and fraught with challenges. Depending on the scope of the effort, it can be run as a slow-burn initiative or a more frenetic and rapid attempt to change the way we work. Either way, like any real journey, unless you know where you’re starting from, you can’t really be sure where you’re going.

Unfortunately, it’s also true that we see many organizations go through multiple attempts to “be Agile” and fail. Often, this is caused by a lack of understanding of the current state or a conviction that, “we can get Agile out of a box.” This is where an Agile Assessment can really help, by providing a new baseline that can act as a starting point for planning or even just provide sufficient information to adjust our course. 

What’s in a Word?

We often hear the refrain that “words matter.” Clearly, that is true. But sometimes humans have a tendency to over complicate matters by relabeling things that they aren’t comfortable with. One example of this within the Agile community is our reluctance to use the term “Assessment.” To many Agilists, this simple word has a negative connotation. As a result, we often see alternative phrases used such as “Discovery,” “Health-check,” or “Review.” Perhaps it’s the uncomfortable proximity to the word “Audit” that sends shivers down our spines! Regardless, the Merriam-Webster dictionary defines “assessment” as:

“the act of making a judgment about something”

What’s so negative about that? Isn’t that exactly what we’re striving to do? By providing a snapshot of how the existing organization compares against an industry-standard Agile framework, an Assessment can provide valuable insight into what is working well, and what needs to change.

The Influence of the Agile Manifesto

When the Agile movement was in its infancy, thought leaders sought to encapsulate the key traits of true agility within the Agile Manifesto. One of the principles of the manifesto places emphasis on the importance of favoring:

“At regular intervals, the Team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”

Of course, this is key to driving a persistent focus on improvement. In Scrum this most obviously manifests itself in the Retrospective event. But improvement should span all our activities. If used appropriately, an Agile Assessment may be a very effective way of providing us with a platform to identify broad sets of opportunities and improvements.

Establishing a Frame of Reference

Just like Agile Transformations themselves, all Assessments need to start with a frame of reference upon which to shape the associated steps of scoping, exploration, analysis, and findings. Otherwise, the whole endeavor is just likely to reflect the subjective views and perspectives of Assessor(s), rather than a representation of the organization’s maturity against a collection of proven best practices. We need to ensure that our Assessments leverage an accepted framework against which to measure our target organization. So, the selected framework provides us with a common set of concepts, practices, roles, and terminology that everyone within the organization understands. Simply put, we need a benchmark model against which to gauge maturity.

Assessment Principles

Measuring Agile Maturity with Assessments

In the world of Lean and Agile, intent is everything. To realize its true purpose, an Assessment should be conducted in observance with the following overriding core principles:

  • Confidentiality: all results are owned by the target organization
  • Non-attribution: findings are aggregated at an organizational level, avoiding reference to individuals or sub-groups
  • Collaboration: the event will be imbued with a spirit of openness and partnership- this is not an audit
  • Action-oriented: the results should provide actionable items that contribute toward building a roadmap for change

Also, in order to minimize distraction and disruption, they are often intended to be lightweight and minimally invasive.

Assessment Approaches

It goes without saying that Assessments need to be tailored to fit the needs of the organization. In general, there are some common themes and patterns that we use to plan and perform them. The process for an archetypal Assessment event will often encompass these main activities:

  • Scoping and planning (sampling, scheduling)
  • Discovery/Info gathering (reviewing artifacts, observing events, interviews)
  • Analysis/Findings (synthesizing observations into findings)
  • Recommendations (heatmap, report, debrief)
  • Actions/Roadmap

Overall, the event focuses on taking a sample-based snapshot of an organization to establish its level of Agile Maturity relative to a predefined (Agile) scale. Often, findings and observations are collected or presented in a Maturity Matrix which acts as a tool for generating an Agile heatmap. Along with a detailed Report and Executive Summary, this is often one of the key deliverables which is used as a primary input to feed the organization’s transformation Roadmap.

Modes of Assessment

Not all Assessments need to be big affairs that require major planning and scheduling. In fact, once a robust baseline has been established, it often makes more sense to institute periodic cycles of lighter-weight snapshots. Here are some simple examples of the three primary Assessment modes:

  • Self-Assessment: have teams perform periodic self-assessments to track progress against goals
  • Peer Assessments: institute reciprocal peer reviews across teams to provide objective snapshots
  • Full Assessment: establish a baseline profile and/or deeper interim progress measurement

Focus on People—Not Process and Tools

Measuring Agile Maturity with Assessments

Many organizations can get seduced into thinking that off-the-shelf solutions are the answer to all our Agile needs. However, even though a plethora of methods, techniques, and tools exist for assessing, one of the most important components is the Assessor. Given the complexities of human organizations, the key to any successful assessment is the ability to discern patterns, analyze, and make appropriate observations and recommendations. This requires that our Assessor is technically experienced, knowledgeable, objective, collaborative, and above all, exercises common sense. Like almost everything else in Agile, the required skills are acquired through experience. So, choosing the right Assessor is a major consideration.

Go Forth and Assess!­

In closing, most organizations that are undergoing an Agile transformation recognize the value of performing a snapshot assessment of their organization against their chosen model or framework. By providing a repeatable and consistent measurement capability, an Assessment complements and supports ongoing Continuous Improvement, while also acting as a mechanism for the exchange and promotion of best practices.

We hope that this simple tour of Assessments has got you thinking. So what are you waiting for? Get out there and assess!

For more information on assessments in the SAFe world, we recommend checking out the Measure and Grow article.

About Stephen Gristock

Stephen Gristock - Specializing in

Specializing in Agile-based transformation techniques, Stephen has a background in technology, project delivery and strategic transformations acquired as a consultant, coach, practitioner, and implementation leader. Having managed several large Agile transformation initiatives (with the scars to prove it), he firmly believes in the ethos of “doing it, before you teach/coach it.” He currently leads Eliassen Group’s Agile advisory and training services in the NY Metro region.

View all posts by Stephen Gristock

Share:

Back to: All Blog Posts

Next: How I Prepared to Teach My First Remote Class

How I Prepared to Teach My First Remote SAFe Class

Teach My First Remote SAFe Class

In March 2020, I co-taught my first SAFe® class. I made a big course Kanban board on the wall with each lesson and designed flip charts for feedback. I printed out the entire trainer guide (trees, RIP) and took physical notes on each page and lesson I was accountable for presenting. I printed and cut out all of the features and stories for the PI Planning simulation, divided up the pennies, and organized the room with pens and sticky notes.

I still have the “business executive” visor I like to show off to friends. Little did we know, those few days teaching that course were our last days in the office together.

In March 2021, I co-taught my first remote SAFe class. I didn’t print out or physically organize a single thing, but I did spend a lot of time preparing: I’d say three to four times as much. This time it was browser tabs, online tools, email messages, and files. And since this was my first teaching environment for any subject in a remote space, I had a lot to learn and explore. 

Luckily, I wasn’t completely alone in my exploration. The SAFe® Community Platform centralized a lot of the resources and information I needed to make the class a success. 

Scaled Agile-provided Preparation

Course enablement. Just as with in-person teaching, mastering the content before teaching it is vital. Listening to SAFe experts discuss the intent of each lesson and subsequently passing the exam was a great (and mandatory) first step.

Remote Trainer Badge. Taking this learning plan helped prime my mind for teaching in a remote context. It gave me confidence and allowed me to see opportunities in teaching remote rather than just its limitations. I got tips from some of SAFe’s best trainers on creative ways to teach, appropriate adjustments, and reframed expectations. For example, even with a pre-course webinar to prepare your students and yourself for the tools and technology to use in class, you should still have a plan A, plan B, and plan C, because anything can happen. 

The SAFe® Virtual Classroom. With Virtual Classroom, I didn’t need to find a collaboration tool, buy a subscription, rebuild all of the activities, and have my students register for it. In one click and with no extra effort, my activities were set. Thank goodness for Virtual Classroom! I could spend my precious time elsewhere instead of tediously recreating activities and adding, copying, and pasting every user story in the PI Planning simulation.

Knowledge-check questions. At the beginning of every trainer guide, there’s a link to a set of quiz questions associated with each lesson written in the style of the certification exam. Right now, it’s still a bit tedious to transfer all of the knowledge-check questions and answers to a polling tool, but this ended up being a highlight for several of our students. It was a great review of each lesson and was a good litmus test to give confidence that the students were learning and retaining information. 

Self-guided Preparation

Reviewing each slide. Getting very comfortable with the content and flow of the course is important to me. This largely means going through each slide and adding notes for stories, metaphors, and analogies—no trees harmed this time. Taking the time to get creative with the content enabled me to set up jokes and prepare realia props to surprise and delight students.

Preparing each activity. This may seem tedious and redundant, but really getting clear on the activities and exactly how they will be performed set both me and my students up for success. The virtual space can be confusing sometimes, so getting crystal clear on resources, breakout rooms, timeboxes, and objectives is key, especially when there are a few ways to run activities. 

Virtual audience engagement research. This means Google searching and YouTube browsing about how to make a remote class effective and fun. I wanted to get suggestions from experts in the general business of video conferencing, from webinars to interactive courses. I learned about alternatives to slide decks, relevant icebreakers, and online tools to keep the class on track. 

Was the class 100% perfect? No. But I went in feeling prepared, taking advantage of several available resources. I took risks and tried new things. And ultimately, I learned from the experience.

I discovered that remote teaching is nothing to be afraid of. For many people like me, it’s simply something new, something different, and something with which to experiment, have fun, and fail fast. In the words of one of my favorite professors, “The best teachers are the ones who try.” So, get caught trying.

About Emma Ropski

Emma Ropski is a certified SAFe 5 Program Consultant and scrum master

Emma is a certified SAFe 5 Program Consultant and scrum master at Scaled Agile. As a lifelong learner and teacher, she loves to illustrate, clarify, and simplify helpful concepts to keep all teammates and students of SAFe engaged.

View all posts by Emma Ropski

Share:

Back to: All Blog Posts

Next: Aligning Global Teams Through Agile Program Management: A Case Study

How We Used DevOps to Rework Our DevOps Course

There’s no faster way to kill a conversation among a non-technical crowd than to begin discussing DevOps. For many, DevOps is that “technical thing” that IT teams do to automate testing. Or, to paraphrase an actual conversation I once had with a client:

“Doesn’t DevOps use that guy Jenkins to monitor something called technical debt so that we can have a cleaner Git, which somehow allows our Kubernetes to Docker? All I know is that our operations people don’t like it when we release on demand, and our annual software releases just deliver last year’s trends too late.”

There are many of us who probably own a small share of the responsibility that has brought about that sort of (mis)understanding. Part of creating an environment that will help a business survive and thrive in the post-digital economy is to do better at explaining the “why” as much as the “what.” To begin making amends for my previous DevOps shortcomings, let’s focus on the “why” of DevOps, and how it led to the recent refactoring of the SAFe® DevOps courseware. 

The SAFe Approach to DevOps

How We Used DevOps

After more than a decade of experimenting and learning, the DevOps community has discovered that effective DevOps entails a deep appreciation for culture, automation, Lean flow, measurement, and sharing (CALMS). In other words, DevOps requires that energy be directed toward each of these areas—not necessarily equally, but in balance—to achieve desired outcomes. SAFe echoes this belief, with one modification: sharing is a natural component of culture, which makes room for ‘recovery’ as a new element. Hence, SAFe’s CALMR approach to DevOps. What’s more, we aim to explore the notion that DevOps only applies to technology. In fact, we’ve found great success applying the CALMR approach throughout our business.

Culture. In SAFe, DevOps leverages the culture created by adopting the Lean-Agile values, principles, and practices of the entire Framework. Nearly every principle of SAFe, from Principle #1, take an economic view, to Principle #10, organize around value, applies to DevOps. DevOps enables shifting some operating responsibilities upstream, while following development work downstream into deployment, and operating and monitoring the solution in production.

Automation. DevOps recognizes that manual processes are the enemy of fast value delivery, high productivity, and safety. This is because manual processes tend to increase the probability of errors in the delivery pipeline, particularly at scale. These errors in turn cause rework, which delays desired outcomes. Automating the Continuous Delivery Pipeline via an integrated ‘toolchain’ accelerates processing time and shrinks feedback cycles. It’s this feedback—from customers, stakeholders, solutions, infrastructure, and the pipeline itself—that provides objective evidence that solutions are (or aren’t) delivering the expected value.

Lean flow. Agile teams and trains strive to achieve a state of continuous flow, enabling new features to move quickly from concept to cash. The three keys to accelerating flow are reflected in Principle #6, visualize and limit WIP, reduce batch sizes, and manage queue lengths. All three are integral to the ongoing optimization of the Continuous Delivery Pipeline. I describe each one below in the context of DevOps.

Measurement. Achieving extraordinary business outcomes with DevOps requires optimizing the Continuous Delivery Pipeline. Solutions, the systems on which they run, and the processes by which they are delivered and supported must be frequently fine-tuned for maximum performance and value. What to optimize, how to optimize it, and by how much are decisions that need to be made on a near-constant basis. These decisions are rooted in Principle #1, take an economic view, and Principle #5, base milestones on an objective evaluation of working systems—not merely on intuition. Thus, the ability to accurately measure delivery effectiveness and feed that information back into relentless improvement efforts is critical to DevOps success.

RecoveryTo support frequent and sustained value delivery, the Continuous Delivery Pipeline must be designed for low-risk releases and fast recovery from operational failure. Techniques to achieve a more flexible release process are described in the Release on Demand article.

Refactoring DevOps with DevOps

How We Used DevOps

At Scaled Agile, we do our best to “Be SAFe.” With that directive, we constantly seek ways to apply the mindset, values, and principles behind the Framework to our daily work. During the continuous exploration cycle within our last PI, Product Management discovered an opportunity to improve our DevOps course to better suit the post-pandemic way of learning. Leveraging our culture, we were able to successfully DevOps DevOps in the PI that followed. Here’s what we did.

MeasurementBy investing in and monitoring measurement, the team was able to identify an abnormality in the system before it materialized into something larger.

Culture of shared ownershipInstead of figuring out who was to blame for the findings, the team focused on figuring out what was taking place in the system and what we could do to resolve it. We conducted customer research, market research, member interviews, and instructor interviews. And we discovered that the reason why people weren’t teaching the DevOps course was that we hadn’t prioritized it for online learning enablement. In short, DevOps was not one of our most taught courses, so economics hadn’t yet dictated that enabling that courseware was the most important job to be done. The people who worked on the refactor were a truly cross-functional group. There were technical team members, such as the Framework SME, design experts and exam designers, and non-technical members, including the Product Owner, Product Manager, operations, business development, and legal. 

Lean flowWith the work identified, we broke down the DevOps course update into stories and managed everything based on the cross-functional capability of the dev team. We prioritized the work based on the economies of job bundling, sequenced it based on dependency, and ranked it based on need. We focused first on updating course content based on known defects and 5.1 updates: a shippable unit of value. We based redeveloping the course storyline on new team capabilities and market feedback: another shippable increment of value. Next, we focused on developing, deploying, and validating the digital classroom based on the newly created assets and the capabilities of SAFe® Collaborate—yet another shippable increment of value. Finally, with all the assets live through a dark launch, we were able to release on-demand based on optimal timing for our training partners.

RecoveryAs mentioned, we released the SAFe® DevOps course update and digital classroom via a dark launch. Meaning that the assets were live and ready to use but available only to a small number of test instructors. As these instructors delivered the updated training via the virtual classroom, team members could note improvement opportunities, correct defects in real time, and in the event of a catastrophic failure, revert the class to an alternate learning environment at a moment’s notice. 

Room for growth: automationAs the team worked through the DevOps update, it became apparent that we overlooked a particular aspect of CALMR in our own adoption: automation. As an organization that creates many digital and print assets with a varying degree of content redundancy, we noticed that we missed an opportunity to save time and better ensure quality through automation. In its most simplistic form, we recognized the benefit of managing a repository for commonly used assets. In a more advanced state of automation, we thought it would be cool to leverage a content management system that would allow us to update all instances of an artefact across all assets from a single repository.

Relentless Improvement

DevOps, like SAFe, Agile, or Lean, is a never-ending pursuit of relentless improvement. Our team was again reminded that no matter how good you are, even if you’re the people writing the playbook, that there are always ways to do things better. DevOps was developed to bridge the gap between software project teams and operations teams to better assure quality and speed within delivery cycles. DevOps comes from the same software-centric roots as Agile, and we’re learning that applying DevOps also extends beyond the problems which it was initially designed to solve.

How may the concepts of CALMR support the type of work you do? Join the conversation and share your experience in the forums on the SAFe® Community Platform (login required).

About Adam Mattis

Adam Mattis is a SAFe Program Consultant Trainer (SPCT)

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

Next: Why the Most Successful PMs and POs Share a Brain