I wanted to share a learning moment I and my colleagues at Scaled Agile had recently. June is Pride Month, and some employees requested that we modify our logo to include the rainbow. This request led to an internal debate about whether altering our logo was a trivial act or a meaningful symbol.
People raised valid points. “Others are doing it. Why aren’t we showing our support?” and, “We don’t do enough externally to support the Lesbian, Gay, Bisexual, Transgender, Queer, Intersex, Asexual (LGBTQIA+) community, so changing our logo feels like an empty gesture.” Ultimately, we decided not to modify our logo but instead encourage an employee-driven campaign that the company could share on its social channels.
Personally, I saw the request to alter our logo as a non-issue. Here’s why: As an openly gay male executive at Scaled Agile, I lead one of our largest global regions. No one has ever questioned my capabilities, and I’ve always felt accepted. As a leader here, I have opportunities all the time to lead by example. And I consistently get feedback from employees that they appreciate my approach. People who know me professionally and personally know I don’t have a “work Brendan” that’s different from my “personal Brendan.” My customers know this too. I’ve always been proud of this, and I feel totally supported in this regard at Scaled Agile.
Scaled Agile participates in Pledge 1% Colorado, and every year we donate a significant part of our time and profits to lots of good causes. While we haven’t yet focused on the LGBTQIA+ community, we do give back to many other underrepresented communities through volunteering and donations. Few companies of our size have matched our commitment to giving back. Our company was founded by a strong team, and we’ve never wavered in our support for the gay community.
Early on in Scaled Agile’s existence, we chose to hire the best talent. And we ended up with a large and enthusiastic LGBTQIA+ employee base. I’m here to say that you can find a place to hang your rainbow hat here with us. Fostering a welcoming workplace where LGBTQIA+ people feel safe, supported, and trusted is giving back, and it’s worth getting loud about. I’m fortunate that I’ve always found these qualities in my employers; I vet them in that regard. Providing an environment where LGBTQIA+ people can grow their skills in a welcoming way is worth more than any donation we could make to an LGBTQIA+ organization.
Many young LGBTQIA+ people struggle and wonder whether they’ll have a safe future. Showing them that we can thrive and choose whatever career path we want is very important to me. There are LGBTQIA+ adults who go to work every day living a tale of two selves: they are fearful, and rightfully so. When people are forced to hide who they are, they miss out on the right to be their authentic selves, and out of preservation, they show up as a different self. I’ve seen the pain this causes. I’m committed to continuing to play a strategic role in growing this company so that more people can enjoy a safe, fun, and respectful workplace. As a member of the LGBTQIA+ community, I think this is the best giveback we can provide.
I’m a big proponent of providing donations to communities in need. You hope your money goes to the right people at the right time for the right reasons. And you trust that the organization is using your funds wisely. But controlling your contribution to the LGBTQIA+ community by hiring us, no questions asked, and providing us with an amazing, supportive team of colleagues and customers, elicits a tremendous feeling of pride in me.
It can be risky for leaders like me to pen posts like this because they’ll stick with you forever. But leading by example means being vulnerable. We should celebrate who we all are together as well as the fact that our company is having a big impact by offering more than just words or donations. I’ll participate in developing our more concrete LGBTQIA-focused initiatives, and in the meantime, we’ll keep on giving.
About Brendan Walsh
As an active member of the Colorado tech startup community, Brendan has enjoyed growing some of the most successful Colorado-based companies for 25 years and counting. He lives in Denver, along with his partner of 16 years, Aaron. The two have had the privilege of living abroad for several years and always looked forward to bringing their life experiences back to Colorado. Their four-legged, rescued son, Rex, rules the house—just to be clear.
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.
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. 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.
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.
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.
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.
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.
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.
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.
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.
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) 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.
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.
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.
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.
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) 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.
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
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 Agile 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
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:
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
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
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.
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 SAFe 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 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.
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
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.
Recovery. To 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
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.
Measurement. By 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 ownership. Instead 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 flow. With 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.
Recovery. As 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: automation. As 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) 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.
POs and PMs are essential to the success of SAFe. While they share areas of concern, both have their own focus. They both care about the Continuous Delivery Pipeline, they both iterate, and they both have content authority around their backlogs. They’re both responsible for continuous improvement, ensuring capacity for the architectural runway, communicating and collaborating on the vision and roadmaps, and much more.
And, they both focus on execution.
The PM leverages Customer Centricity and Design Thinking to reason about product enhancements, new product ideas, as well as innovation. The PO focuses on flow for development, release execution, and incremental delivery. And, they both embrace the Continuous Delivery Pipeline and the DevOps mindset.
But there’s another element to the importance of their roles: their relationship with each other. The most successful POs and PMs share a brain.
There are many aspects to why this matters, so let’s synthesize them into three main “whys.”
Knowledge transfer, information coherence, and flow
OK, that’s actually three in one, but I put them together for a reason. These roles share a common goal. To inspire and transfer knowledge from the brains of who’s closest to the customer (PMs, Business Owners, etc.), into the brains of those responsible for execution (POs and teams). And, they need to do this with the highest possible level of information coherence, while removing delays and achieving flow.
Here’s an example from a recent PI Planning event I attended. The first day went swimmingly. The management problem solving workshop resulted in six adjustments to planning that were designed to help the teams. The PM spent 30 minutes kicking off day two talking about the adjustments and not too many people asked questions. But during the breakouts, all hell broke loose. The PM texted me saying, “I don’t think they heard a word I said!” The teams and POs argued about the changes, and this caused total chaos. All of which resulted in a huge “flow stoppage” to the entire PI Planning event. Looking back, I realized that the PM didn’t socialize the changes with the POs before day two kicked off, and the POs hadn’t bought into the shift. This completely interrupted any knowledge transfer and information coherence. Why did this happen? Because the PM and POs didn’t share a brain around the changes.
Transparency, content authority around their respective backlogs, and decentralized decision making
SAFe is a series of connected work items, some represented in Kanban, and others represented simply as backlogs. The Team backlogs are a combination of work being pulled from the Program Backlog with work from the local context. With that content, authority comes great responsibility to the product or solution, as well as the enterprise. The Program Backlog comes into PI Planning in the form of economically prioritized work items (Features).
Product Management leveraged their stakeholder management network as input to prioritize the work so that the teams can pull work for the PI that has the highest value to the business. The team backlog comes into PI Planning in the form of capacity allocated for other work items (maintenance, exploration, etc.), and is also prioritized, but slightly differently. The team backlogs are prioritized mostly for flow and execution of the value being pulled, which doesn’t necessarily align directly to the actual WSJF of the Program Backlog.
For this to work, POs and PMs need early transparency into both sets of backlogs so they can make Lean and Agile decisions around the work, and maintain content authority around their respective backlogs. In other words, they need to share a brain around all of the work. Specifically, what capacity allocation are we recommending for maintenance? For refactoring? For exploration? And for new Feature development? What if something happens? What are our working agreements? By sharing a brain around these aspects and working agreements, POs and PMs can make real-time decisions as well as decisions around the backlog in which they have content authority.
Sharing a brain builds trust
We know that an environment that has trust creates a sense of safety for everyone involved. When PMs and POs really start sharing a brain and trusting each other to make decisions, magic happens. This is probably last on our list, as it’s the foundation for the previous two “whys.”
I’ve been fortunate enough to have shared a brain with a few awesome PMs. And the impact of these relationships had real quantitative value. For example, literally anyone on the train could ask either of us a question and they’d get the same answer. This was so incredibly powerful. No more delays in answers or direction. No deviation from the vision. While of course we always want to encourage divergent thinking, there are always aspects of the backlog that have a strong answer (and direction), and others that could use a more collaborative approach. Knowing that both of us could be trusted to have the same answer controlled any backlash, but also created that sense of trust. The teams literally saw us as one, and whether the answer was: “I need to collaborate with my PM,” or a “specific answer,” they trusted us both implicitly. Just as we trusted the teams to deliver, they became extremely predictable in delivering against their objectives. This bi-directional trust not only helped us achieve our highest value in the shortest amount of time, but it created behavior models for others throughout the enterprise to follow.
The How
Now that we’ve discussed the why, let’s look at the how. How the heck do PMs and POs actually share a brain?
Well, it starts with some “symbiotic-ness,” First, having a common passion around the work creates some synchronicity as well as symbiosis. Then, learn to like each other, evolve, and explore common interests. Eventually, if enough time, emotional intelligence, and willingness occur, the PM and PO grow to love each other. This creates the ability to have extremely healthy dialogue, heated debate with no attachments to preconceived outcomes, and of course, that brain sharing.
Start with something simple. Get to know each other. Ask about each other’s family, their values, and their personal aspirations. Make lunch dates and keep them. Share food, common interests, and personal time. Realize that a successful relationship relies on true personal connections, not just what happens at work.
Here’s another example. After working with one particular PM for some time, her house burned down. The CEO of the company called me to let me know, and specifically asked that I didn’t call her. Well, at that point, we had shared such a deep relationship that I asked myself, “What would she want me to do?” She would want me to call her. So, I did. Together, we cried. She shared what she was going through. Of course, I offered to help in any way I could. She said that just the kindness of the gesture was enough for now, and that she promised she would ask for help when she got through the trauma and devastation at hand.
None of that could have happened without the power and evolution of our POPM relationship. Sharing a brain. Getting to know each other. Sharing knowledge and understanding. Being transparent, while playing our own roles on the train. Creating trust within the organization that anyone could ask either of us a question and get the same answers. All this may seem like the soft stuff, but it’s how we grow our social networks, our relationships, and open up to share ideas, values, and opinions on how to deliver the highest value to our customers and society.
After all, who doesn’t want that?
Check out these articles to get different perspectives about PO and PM roles, responsibilities, and relationships:
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.
As organizations begin their Lean and Agile journey with SAFe®, SPCs will introduce a tool designed to help organizations determine the best, most logical place to launch their first Agile Release Train (ART). The Value Stream and ART Identification Workshop are designed to help organizations identify the sweet spot where an opportunity to deliver value intersects with a clear problem to solve, leadership support, a clear product or solution, and collaborating teams.
It’s challenging to meet the criteria mentioned above, which is why many are tempted to launch ARTs within easier-to-identify constructs such as organizational silos. This rarely works. As we know, value often does not follow the organizational hierarchy. However, it’s important to understand that value stream identification is the first step in an ongoing practice of flow management to optimize the speed of delivery, quality, and customer delight.
Why we perform value stream identification
Words matter, and there’s a clear distinction between value stream identification and value stream mapping. We advocate identifying value streams as you get started with SAFe. Value stream mapping is an ongoing practice of understanding, tuning, and planning how the organization will deliver value against its strategy in the long term.
Value stream identification is something we seek to accomplish in a day or two
Value stream mapping is a practice that we sustain indefinitely
Depending on an organization’s state of maturity in the realm of business architecture, one can inform the other, and neither is independent of the other.
The role of business architecture
The role of business architecture is to provide clarity of how an organization’s capabilities and infrastructure come together to deliver business outcomes. The business architect is responsible for developing artifacts that help the organization operationalize strategy and assure the operational and technological enablement of core capabilities across value streams. In the context of this post, it’s important to understand the difference between how business architecture and SAFe use the word “capability.”
Capability, as defined by SAFe: Artifacts that may originate in the local context of the solution or occur as a result of splitting portfolio Epics that may cut across more than one value stream. Another potential source of capabilities is the Solution Context, where some aspect of the environment may require new solution functionality. In a SAFe context, the delivery of a capability requires collaboration between more than one ART.
Capability, as defined in business architecture: An expression of what a business does and can do.
Though when exploring the discipline of capability modeling, the nuance between the two definitions disappears, the terms in common usage may cause confusion early on. It’s likely that we’ll dive deeper into the relationship between SAFe and business architecture and provide more clarity of how the two disciples come together on a midterm horizon. To provide additional understanding of how these words may come together, consider the context of a shipping services provider.
Capability: Package tracking.
Process: Generate tracking number.
Value stream: From order received to package delivered.
System: System ‘X’ is the system used to realize the tracking capability.
Service-oriented architecture (SOA) or microservice: Tracking could be an SOA service or microservice depending on the architecture of the system. But either instance refers to the specific mechanisms that deliver the intent of the capability.
Capability (as used in SAFe): Real-time package tracking.
Notice how capability, as defined in SAFe, extends the functionality of how capability is defined in the context of the business architecture discipline. This may give an indication of how future guidance could evolve.
Value stream mapping
The goal of value stream mapping, as defined in business architecture communities, is to map value delivery processes from concept to cash within a business. The SAFe definition of an operational value stream, the sequence of activities needed to deliver a product or service to a customer, aligns with most other common definitions of the term. SAFe also provides distinction and guidance for interacting with different types of operational value streams to include fulfillment, manufacturing, software production, and supporting value streams. Depending on the altitude of your perspective within an organization, these categories of value delivery may seem too granular, too broad, or just right.
In the discipline of business architecture, architects are responsible for mapping an organization’s value streams from macro to micro. For example, a top-level value stream map for a shipping services provider may look something like this.
Example: top-level operational value stream
This simplistic view likely represents thousands of integrated software systems, multiple complex distribution hubs, scores of human hands, and millions of packages each day. Through the discipline of value stream mapping, business architects have the responsibility to understand and map how an organization does business. It starts with the macro perspective illustrated above. And continues to the micro level of how, within the context of the routing box above, shipping crates are planned, packaged, and sequentially loaded into trucks or aircraft given the specific weights, classes of service, and destinations of parcels on any given day.
Example: routing value stream
SAFe seeks to optimize the operational and development value streams that make the top-level run. In the example above, there are likely operational value streams within the distribution centers that physically move packages, others that control the movement of vehicles, and still others that produce the technology to seamlessly coordinate those events, which is typically where we operate in SAFe.
SAFe focuses primarily on the development and management of development value streams, with the intent of optimizing the design/validate/deploy activities that make an operation run. Though as the world becomes more digitally integrated, the conversation is likely to evolve.
Many organizations seeking to embrace the methods outlined in SAFe lack an existing value stream body of knowledge. And one of the first steps to take to achieve a successful transformation is to begin focusing on value. The Value Stream and ART Identification Workshop helps provide the value perspective, and will likely surface organizational challenges that have historically served as a barrier to a value focus. These include communication barriers, duplicative technology systems, and business processes, and a lack of alignment within the organization. These challenges are not because of SAFe, but because the organization seeks to optimize for speed of delivery, solution quality, and customer satisfaction. You must address the problems that surfaced in value stream identification to achieve the desired outcomes.
Once an ART is launched, the work of optimizing for value delivery continues. Launching an ART will lead the organization with a powerful step forward. But to truly optimize the entire system, you’ll likely need to invest in value stream mapping through and by embracing business architecture practices.
Capability mapping
With the value stream identified, an evolution to business architecture seeks to understand the capabilities of an organization. Simply put, knowing how each of the processes on the value stream map incrementally supports the delivery of value. Capabilities provide the organization with an as-is view of how the organization operates.
For example, the ultimate goal of someone who ships a package is for that package to arrive at its intended destination on time. The capability of tracking intends to provide the customer with the assurance that their goal, the aim of the value stream, will be fulfilled as expected. Additionally, it provides transparency should the service expectations fall short.
Example: Business capability
Capability modeling
Capability modeling is an extension of capability mapping that helps inform how the business may need to alter its capabilities to achieve some sort of strategic intent. That could include improved customer satisfaction, more transparency, or even the expansion or contraction of the organization.
Example: Implementing strategy with capability modeling
For organizations that want to compete in the digital age, the ability to leverage business architecture and capability modeling when testing an Epic’s hypothesis is the ultimate fuel to feed ARTs. Effective Lean Portfolio Management helps provide the objective clarity to understand the impacts of strategy and validate hypotheses. That vision clarifies how business architecture and capability mapping investments work along your journey to business agility and thriving in the digital age.
Where to start
Some level of business architecture capability exists in many organizations at some level. The best place to check if your organization has existing value stream or capability maps is with the office of the chief strategy officer.
If your organization doesn’t have existing artifacts, the SAFe Value Stream and ART Identification Workshop is a great tool to continue the conversation beyond informing the launch of the first ART. You can use the guidance in the toolkit to identify the operational value stream and apply it to your altitude of influence to fully articulate how the business area delivers value. You can reinforce your map by fully identifying the people who work within the value stream, the systems that support the value stream, and the people who work on those systems—all as guided by the workshop. The main differentiator between this effort and the initial Value Stream and ART Identification Workshop is the intent of mapping with more precision for the purpose of developing a deeper artifact, versus the initial conversation which is focused on finding the best place to launch an ART.
After you’ve articulated the value stream, you can reinforce it by considering guidance in the SAFe® DevOps course, which helps provide visibility into lead time, process time, and cycle time. Then, with the value stream articulated and the flow metrics in hand, the organization will be able to make informed decisions on how to best improve the rate of flow within the value stream. From there, opportunities will likely emerge to expand the work into other areas of the business, explore capability mapping, expand to experience architecture, and more.
If there’s one thing I’ve learned from my years of working with Lean, Agile, and SAFe tools, it’s that well-intended, value-add work to better the organization and customer experience always yields new opportunities.
Good luck!
About Adam Mattis
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.
On the surface, the foundations of job sequencing in considering the Weighted Shortest Job First (WSJF) prioritization schema seem logical. Do the smallest job with the greatest cost of delay first to deliver the greatest economic benefit. Though, in practice, it can be much more challenging. To survive and thrive in the post-digital economy, organizations need to change how they produce products, interact with customers, and define and prioritize work. To succeed in each of these areas requires a significant shift in organizational behavior, including how leaders interact with their peers.
But, how did we get here?
Why does what seems right feel so hard?
What can we do?
Siloed behavior and organizational politics
Organizational structure and a slow operating cadence have created a specific environment within workplaces. One where large organizations encourage people and leaders to prioritize the work system over customer needs and speed to market.
It’s not their fault; it’s the system they inherited.
In the decades following the Second World War, the capacity to serve consumer needs had been owned almost entirely by large organizations with the capital to establish complicated supply chains and manufacturing processes. These organizations, not the consumer, dictated products, delivery cadences, and market rhythms. Until recently, those behaviors proved profitable.
2001 proved to be a proverbial “canary in the coal mine,” which indicated business disruption on the horizon. With the mass adoption of the internet, software distribution was no longer reserved only for organizations with the capital and infrastructure to produce thousands of diskettes and manuals. The dot-com era brought forth an environment that allowed any developer with access to the internet the ability to distribute software without the overhead of production. If they intended to compete, large software companies realized that they needed to be more customer-centric, faster, and value-focused. Thus, the drafting of The Agile Manifesto.
In 2021, accelerated by COVID, nearly all businesses across every sector are facing the same awakening that software companies did in 2001—no industry is safe from disruption. This time around, we’ve witnessed minimal to zero barriers to entry, a global workforce that has thrived working from anywhere, supply chains that are more nimble than ever, and desktop manufacturing capabilities that are largely inexpensive.
If storied businesses aim to survive in the threat of total disruption, they must change organizational behaviors related to strategy, workflow, and systemic behavior. Though, to change these behaviors, it’s important to understand why organizations behave the way they do.
Win culture
Win culture is pervasive within the organizational system and is the greatest challenge to overcome. The culture of winning has been hardwired into many of us from a young age, was fueled throughout the educational experience, and is carried forward into our careers.
Starting in elementary school, students are tested and ranked based on their perceived abilities. These tests determine who is placed in gifted programs, remedial programs, or in a more traditional track. Parents desperate to see their children succeed and outperform their peers push them into after-school STEM programs, language studies, and other activities. Once on the advanced track, students compete to be among the best of their group. Only the best of the best will be admitted to the best colleges. Only the best from the best colleges will be accepted into the best graduate schools and offered the most prestigious jobs.
From there, the need to win is amplified in the workplace. As one climbs the corporate ladder, the opportunity for advancement shrinks and the need to win over one’s peers becomes more frantic. Winning sometimes surpasses the team, the customer, and even the organization. It becomes about beating the competition to achieve more power, prestige, and income.
Sound familiar? This is the system we have built. To paraphrase W. Edwards Deming, a system left unmanaged becomes inherently selfish, and only management can change the system. It begins with you and how you make decisions related to defining and prioritizing work.
Take an economic view
The first principle to embrace in defining and prioritizing work, as supported by the Scaled Agile Framework® (SAFe®), is to take an economic view.
In any organization, for-profit, nonprofit, and everything in between, economics must be the primary determinant of job sequencing. Or, which jobs can I do in the shortest amount of time that will generate the most revenue, save the most on expenses, or reduce our exposure to the greatest amount of risk?
Some may argue that the statement above may not seem very customer centric, but I would argue. Consider the perspective of a nonprofit, where the ultimate goal is to serve the most beneficiaries as possible while being a good steward of donor dollars. To be successful in this regard requires taking an economic view. Consider the perspective of a for-profit, and a quote from Sam Walton, founder of WalMart. “There is only one boss. The customer. And he can fire everybody in the company from the chairman on down simply by spending his money somewhere else.” If an organization is building products that don’t represent the greatest benefit to the customer when the customer desires the benefits, the customer won’t buy the products or services. To understand which products/services/features the market demands, we must take an economic view.
Apply systems thinking
With an economic perspective in mind, the next principle supported by SAFe is to apply systems thinking. Or, accept the very real possibility that the most important job for an organization to pursue may not be the job that you personally feel is most important. One of the biggest problems with organizations that embrace a hierarchy without the benefit of a secondary operating system is that it’s easy to become myopic. People become enamored with the success of their silo and often forget that their organization alone doesn’t deliver customer value.
Systems thinking encourages us to consider the whole value stream and customer journey. The principle also reminds us that the quality of a system (or customer experience) is only as good as its slowest/most painful component. As implied by Lean, to establish flow of any sort, we achieve the greatest benefit when we seek to optimize the slowest/weakest/most painful parts of the system. By applying systems thinking as part of an economic prioritization framework, we are reminded that the work we do is part of a system. The greatest benefit to that system may be investments in areas outside of one’s own area of direct influence.
WSJF
It’s hard to make decisions about the most appropriate prioritization of work. The difficulty is amplified when arriving at that prioritization requires consensus among peer groups that are typically in fierce competition with one another.
In my consulting career, I’ve seen many scenarios. Some where the people required to collaborate for prioritization struggled to even speak to one another. Some where people were reluctant to acknowledge that the task of another was more important than their own. As consultants and change agents who may be facilitating these prioritization discussions, we must lead with empathy. Project culture in organizations was often predicated with a “do this, or else” delivery requirement. At best, missed project delivery would kill a career. At worst, it could result in immediate termination. Many leaders and executives are in a position where their long-term bonuses are still tied to this sort of incentive, or have a hangover from management paradigms of the past. Overcoming these very real fears will require leading by example and providing psychological safety. Consider collaborating with an organization’s change partners to develop a strategy for helping decision-makers evolve with grace; pushing will not yield the desired result.
WSJF, the prioritization tool introduced by Reinertsen and applied by SAFe aims to make this difficult task easier. We consider WSJF in four micro-conversations:
Perceived user-business value
Time criticality
Risk reduction and/or opportunity enablement value
Job size
The conversation is facilitated by reviewing each of these elements in isolation from the others. For example, if we have a list of ten jobs, we’ll first determine the user-business value score for each using a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20) and scoring guardrails. The guardrails should represent work that has been done previously to ensure consistent estimation. In my experience, I’ve found it helpful to have points of triangulation identified for each element of WSJF that represent a 2, 8, and 20.
WSJF is calculated by first determining the cost of delay through the summation of the user-business, time criticality, risk reduction and/or opportunity values, and then divided by job size. Based on the definition of the feature at the time, architects and other people who are responsible for delivering the work, will determine the job size independently of the other values.
Considering Reinertsen’s guidance, we agree that the jobs with the highest WSJF value represent the highest-value jobs that can be done in the shortest time possible.
It’s also worth noting that the WSJF prioritization isn’t final. We need to keep other factors top of mind, such as dependencies and availability of skills. And we need to make sure we always consider the economics and greatest benefit to the system.
Just-enough thinking helps us move faster
Consider the 10th principle behind the Agile Manifesto: the art of maximizing the amount of work not done is essential. We know that given the 80/20 rule, 80 percent of the value of a product comes from 20 percent of its features. The rest are rarely if ever, used.
Consider your bank’s website. I suspect that when you log into your account, you focus on three primary functions: reviewing your checking account, reviewing your savings account, and transferring money between the two. Not that loan applications, external transfers, and mobile deposits aren’t important. But to get the most value in the shortest amount of time possible, you likely focus on surfacing checking, savings, and transfer first. Additional functionality would come in a subsequent release. Waiting until all of the functionality was complete before launching the online banking platform likely seems foolish in the context.
WSJF forces us to focus on the features or ideas that are going to drive the most value at a given point in time. What are the checking, savings, and transfer functions relevant to you? Are you choosing to look at the work as a bank website, which is really big and would fail the prioritization conversation every time? Or have you broken the work up into smaller, high-value chunks? If you want your work to get prioritized, make sure that it’s small and highly valuable in the eyes of the customer. Small jobs move through the system (and delight customers) faster.
It requires leadership
Shifting our approach to prioritizing work is hard, but so is meaningful change. Winning in the post-digital economy depends on an organization’s ability to rapidly shift to meet changing market conditions and customer demands. Leaders who position themselves and their teams to be resilient in the face of change will win the digital future. Those who delay or don’t change will struggle to remain relevant.
What’s probably hardest of all is that for those in a leadership role, it’s highly unlikely that anyone will give them permission to behave in this way. In fact, doing so may come at great risk. Being a change agent is a difficult and thankless role, but one that organizations need now more than ever. If you’re a leader reading this post, it’s likely that your organization is already on the path to changing its work habits. It’s now up to you, the leaders, to determine how successful the change, and your organization’s future, will be.
About Adam Mattis
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.
We use cookies to analyze website performance and visitor data, deliver personalized content, and enhance your experience on the site. Cookie Policy. By clicking Accept you consent to the use of all cookies. Otherwise click Adjust Cookie Settings.
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
