“I am so glad I did it. It is unreservedly the single most important thing I have done in my career. If you are a seasoned professional with a commitment to lifelong learning and are wondering what your next career move might be, I highly recommend you take a look at the SPCT program.”
—Michael Casey, SPCT, Agile Big Picture
As more organizations engage with SAFe®, it’s even more critical that we have knowledgeable, experienced SAFe leaders to help transform large enterprises and continue to shape the way SAFe is being implemented. If you have deep SAFe knowledge, are a lifelong learner, are SAFe Practice Consultant (SPC)-certified, and excel in training and coaching, I invite you to consider becoming a SAFe Practice Consultant-T (SPCT).
“As is the case with any certification, you should carefully evaluate SAFe instructors and consultants, and make sure that they have demonstrated experience that is relevant to the role you are asking them to take on. Do not rely on certifications alone as a measure of the skills of a consultant or prospective employee. A notable exception to this is the SAFe Program Consultant Trainer (SPCT) certification[now SAFe® Practice Consultant-T], which does require demonstrated experience with Agile, software development or product management, training and consulting. If you’re hiring someone who has [an] SPCT certification, you can be confident that they do have experience in these areas, as well as experience with SAFe implementation at multiple organizations. However, SPCTs are in short supply. As of February 2020, there are fewer than 100 people worldwide holding this certification.”
— Gartner, “A Technical Professional’s Guide to Successful Adoption of the Scaled Agile Framework (SAFe),” Kevin Matheny, Bill Holz, 13 April 2020
SPCTs are among the most highly regarded SAFe experts in the world. They are also the most sought-after SAFe Trainers, SAFe Trusted Advisors, and SAFe Transformation Architects among enterprises seeking to improve their methods of working and pursue business agility.
As transformation catalysts, SPCTs share their vast industry expertise and skills through teaching, coaching, and handling the most challenging SAFe implementations. And they are experts at communicating, consulting, and creating SAFe knowledge.
SPCT is the most advanced certification you can achieve with SAFe and can be career-changing through job advancement and new opportunities.
SPCT credentials bring the highest level of credibility, which opens doors for you and generates confidence within the organization that you’re helping to create the highest-quality SAFe implementation.
That said, you should know that our selection process has very high standards, and not everyone will get in. To be accepted into the program, you must not only meet the skills and experience prerequisites but have presence and gravitas. The requirements and expectations are slightly different for partners and enterprise employees.
Nominees must either be sponsored by a Gold Partner or an enterprise customer with a SAFe® Enterprise Subscription. However, both must be full-time employees of their respective organizations and are expected to have several years of experience in the tech industry, with five years of Lean-Agile experience and five years of software/systems/product experience.
Here’s how the process works:
Get nominated: If you or someone you know would make a good candidate, request access to the SPCT portal by sending an email to spct@scaledagile.com. Through the portal, you can submit your documented accomplishments as you achieve them.
Have an interview: After your nomination requirements have been reviewed and accepted, you’ll have two screening interviews with SPCT guides. Our team will then determine whether you’d be a good fit for the program.
Attend Immersion Week: If you’re accepted, you’ll be invited to attend SPCT Immersion Week (currently, we hold three to four classes per year) where nominees showcase their knowledge, skills, and abilities in training and consulting with SAFe. You’ll also learn how to teach an Implementing SAFe® class and may even work on a class project that contributes to SAFe’s intellectual property.
Complete field experience: After Immersion Week, you’ll need to complete additional certification requirements that include teaching SAFe classes, completing SAFe implementations, and finishing the required readings.
Co-teach an Implementing SAFe® class: Lastly, you’ll participate in a pairing test by co-teaching an Implementing SAFe® class with one of our guides. During this class, we’ll evaluate your presentation, training, and coaching skills.
I believe becoming an SPCT is a valuable and rewarding career goal to aspire to—but I’m not the only one. Here’s what some of our SPCTs have to say:
“SPCTs are differentiated in the marketplace. The SPCT certification is rare and the knowledge and expertise it represents is valuable and much in demand.”
—Simon Chesney, iSPCT, Western Digital Corporation
“Becoming an SPCT takes hard work, but it will pay you back many times over what you put into it in personal growth and career advancement. Get on board the SPCT program and you won’t look back!”
—Michael Casey, SPCT, Agile Big Picture
I encourage you to explore what it takes to become an SPCT to see if this would be a good fit for you or someone you know.
Adam Mattis is a SAFe® Fellow and SAFe® Practice Consultant-Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across various 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.
This is the fourth post in the Practice Makes Permanent series. You can get caught up by reading the first, second, and third posts.
Any SAFe® implementation relies heavily on one of the 10 Critical Success Factors: Real Agile Teams and Trains. Let’s break this conversation down to make it easier (small batches, right?) and talk about the “Real Agile Teams” part (the next blog in this series will address the “and Trains” part). The “Agile Teams” article does a great job of describing cross-functional, high-performing teams.
What is a real Agile team? In this post, I hope to avoid the standard message about “what is a team?” and instead share some thought-provoking ideas about what a true
is.
True Agile Teams
I came to a discovery a few years ago: there is no such thing as an Agile team.
Think about it. The Agile Manifesto Principle 12 states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” To me, this means that a team never arrives at true agility, but is constantly striving toward agility. Sure, you can call your team Agile. But, as soon as your team believes they have “arrived,” they have begun to stagnate. True agility is only found when we’re eager to learn what’s next to improve, and when we realize how much room for improvement still exists.
If you’ve ever rowed a boat upstream then you know what happens when you stop rowing—you go back downstream. There is no steady state. If you’re not moving forward, you’re moving backward. This is the reality of relentless improvement and of the spirit of Agile Manifesto Principle 12. Your team(s) may have made incredible progress towards agility, but until you realize it’s a never-ending journey, your path forward will always be in jeopardy.
Empowered Teams
Leaders often tell me that they want to empower their teams because they believe that empowered teams can deliver more value. That’s a valid belief, but leadership often doesn’t understand that our natural state is empowered. In his book Turn the Ship Around Captain David Marquet stated:
“We’re taught the solution is empowerment. The problem with empowerment programs is that they contain an inherent contradiction between the message and the method. While the message is ‘empowerment,’ the method—it takes me to empower you—fundamentally disempowers employees. That drowns out the message.”
In other words, to empower teams (and team members), we must first acknowledge that we have disempowered them through the systemic constraints we have created. If you want true Agile teams to constantly strive toward agility, the secret is to get out of their way. Create an environment with complete clarity on what needs to be done, then trust the competency of the people you have hired to do the right thing. As Marquet stated, “We realize that we don’t have the power to give these talents to others, or ‘empower’ them to use them, only the power to prevent them from coming out.”
So how do you empower teams?
Remove Constraints around Team Members
In Team of Teams: New Rules of Engagement for a Complex World, General Stanley McChrystal observed, “For people who perceived themselves as skilled workers, being recast as mindless cogs in a larger machine was degrading.” Businesses hire the best and the brightest they can possibly find, but in many cases, these skilled people are used as the “mindless cogs” in a machine. They’re asked to do small, separated components of work without being allowed to see or add value to the system overall. In many cases, this is due to a lack of clarity. The teams are given only enough information to solve the task at hand, but not enough to apply their shared intelligence to solve the overall problem in the best way possible.
To begin correcting this, apply SAFe Principle #9: Decentralize decision-making by providing clarity of mission. Here is an easy way to get started:
Select a decision that typically requires sign-off or approval by management or leadership. Deploying to production is a common example.
Ask the person that approves this decision what they are using as criteria to make the approval decision.
Work with the teams to create a framework that will give the approver the confidence that the decision is being reviewed correctly.
Provide the information that the approver has to the team so that they can make the decision by combining what they know (local context) with the approver’s vantage point.
Let the team make the decision but allow the approver to see and hear the decision as it’s being made. I like using Marquet’s approach to this practice by having the team state something like: “We intend to deploy this package to production. All functional, security, and compliance tests are passing. All code has been checked into version control. Appropriate code reviews have been completed. The rollback process is in place and has been tested.” Using this statement of intent is a great way to allow teams to make the decision while keeping the approver in the loop. Over time, the approver will gain confidence in the team’s ability to correctly determine this decision.
Now you can move on to the next decision. And the next, and the next…
Change the Culture
Apply SAFe Principle #8: Unlock the intrinsic motivation of knowledge workers by building a culture of psychological flow.
Psychological flow is a concept stemming from a 1975 study by Mihály Csíkszentmihályi who measured test subjects’ happiness metrics at random times throughout their days. Csíkszentmihályi discovered that people are at their happiest when they are in an environment of:
Intense and focused concentration on the present moment
Merging of action and awareness
A loss of reflective self-consciousness
A sense of personal control or agency over the situation or activity
A distortion of temporal experience, as one’s subjective experience of time, is altered
Experience of the activity as intrinsically rewarding also referred to as autotelic experience
Boiling this down, people are most happy when faced with a clear challenge that’s not too difficult to achieve and is intrinsically rewarding.
If you read my previous blogs, then you know that I’m also a motorcycle road racer and instructor. I have experienced psychological flow many times when in a really good battle with fellow competitors. We all know the finish line, we all know the risks (some better than others), and we are hyper-focused on achieving our goals. This is my happy place. And one of the best parts of this flow is the ability to talk with my fellow racers, who previously wanted to beat me to the finish line but now want to share the experience, after the race.
There are many ways to improve team culture, but incorporating psychological flow is a critical component. We all hear about “self-organizing teams” in Agile, but this doesn’t mean the teams self-form. It means they are formed with a purpose and given specific challenges to overcome with minimal guidelines. Leadership’s motivation is to remove impediments from their team’s path even if the leaders are the key impediment.
If you want to have real teams striving toward agility, one of your first steps is to ensure they are properly challenged. Don’t bring them long lists of requirements. Instead, bring them a problem to solve or an opportunity to embrace. Then step back and watch the engagement begin. Culture changes every day. Take purposeful steps to create the culture needed for real Agile teams.
Crave Fast Feedback
We’ve all heard the need to “fail fast.” At this point, it’s almost cliché. But does it mean we set the teams up so that they will fail quickly? That sounds very demotivating. What fail fast really means is to create an environment where it’s safe to fail. We set out on paths that seem valid, but we continue to look for qualified data that helps with the pivot-or-persevere moments.
Two things need to happen when we hit those pivot decisions. One, celebrate that we were able to truncate an invalid path before pursuing it too far. Two, incorporate the learning from this pivot so that we’re better prepared to find more successful paths and narrow in on the right specifications. For more on this topic, review SAFe Principle #3: Assume variability; preserve options.
Real Agile teams crave feedback that’s accurate, timely, and useful. Teams need fast feedback to quickly fail and invalidate paths; otherwise, they begin to lose focus and validated direction. Do you want to see your teams striving towards agility? Create an environment where feedback continuously flows to the teams.
“Team Leader” Is an Antipattern
Well, at least in the conventional sense. Team leads typically have one or more of these traits:
They’re the person who has exhibited the most skill
They’ve been with the company the longest
They have the most application or product knowledge
But are those the right reasons to look to this person for leadership?
All of us have worked with the “rockstars” of product development. They always have the answer, they can solve just about any problem, and they seem to know how everything works. But why don’t the rockstars create a rock band? Shouldn’t those with that much skill, experience, and knowledge try to bring others up to their level rather than continuing to stand out from the crowd? Solos are great, but we all want to hear music from the whole band.
Let’s look at a much more successful team lead approach, the Kaizen leader. In my experience, the whole team thrives when its leader is focused on continual, relentless improvement. Since leadership should be a role that is held as needed (rather than a title), team leadership can switch from one person to another as new improvement opportunities arise. Create a team environment where this is part of the culture and becomes part of the team DNA.
Getting Started
When talking about enterprise transformation with internal change agents, I often hear “that won’t work here” or “our culture just doesn’t work that way.” You know what? They’re right. Not with the current culture or reality.
However, remember that culture changes every day. Our job is to implement some of these team approaches to create a culture where transformation can really thrive. Teach, learn, and focus on the fifth lean principle of Pursue Perfection: “Perfection is like infinity. Trying to envision it (and to get there) is actually impossible, but the effort to do so provides inspiration and direction essential to making progress along the path.” To pursue perfection in a team is to be more excited about the journey than the destination. Teach your teams to view the pursuit of perfection as a worthwhile but never-ending journey of improvement.
I hope this post helps you to look at things through a different lens. Look for the next post coming soon that will add some of the same thought-provoking concepts applied to the ART.
About Dwayne Stroman
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
It was May of 2012, the year that the Mayan calendar said the “great cycle” shall come to an end. And with every cycle comes a new cycle. This new cycle was the beginning of an evolution of knowledge, sharing, and learning around how society builds the world’s largest systems.
For those of you who’ve followed the history of the Scaled Agile Framework® (SAFeⓇ), you’ll remember that the book Agile Software Requirements had just been published in 2011. And you’ll also recognize this book as the foundation and initial version of the Scaled Agile Framework. Just open the front cover and you’ll find Dean Leffingwell’s initial “Big Picture” rendition of the Framework. The book itself was fueled by Dean’s 2007 — 2008 blog series, where he published the initial articles and concepts within Scaling Software Agility and Agile Software Requirements, both books that helped move the market.
The book unfolds the “why” behind the Framework. Dean discerns that to scale agility, an aspect of Lean is requisite. He further goes on to state that Lean is required to scale agility because of its focus on value streams, principles, and tools that enhance value delivery to customers and its elimination of waste in the development process. You’ll also recognize the influence of Don Reinertsen’s Principles of Product Development Flow as some of the early concepts within the Framework. What you may not know is that the publication of Don’s book caused Dean to go back to the drawing board and rewrite his book.
And for those who know Dean personally, you know that respect for people and culture is a passion of his that continues to be prevalent in Lean as well as in SAFe.
Now, while writing and sharing the book was clearly an affection of Dean’s, taking the knowledge and research in the book and translating it into a learning experience was also a passion. Today marks the anniversary of the first Scaled Agile Framework Certification class!
#1 SAFe Program Consultant Certification, May 25, 2012
Roughly 30 curious agilists attended the first SAFe® Program Consultant (SPC) certification. The course was a bootstrapped effort, invite-only. I remember Dean personally reaching out to those who had leveraged the early concept of SAFe.
At the time, I was a product owner. I was honored when my Lean leader said “yes” to funding and allowed me the time and opportunity to learn and evolve my knowledge of my role and how to better scale and build systems that our customers needed.
Taught based on V0.94 of the Framework (isn’t that a work of art?), the course introduced the concepts of Lean and Agile, roles and responsibilities, and the practicalities of scale. The class format was similar to today’s, with the first two days about the mindset and principles and the second two days focused on implementation techniques such as identifying value streams and “finding the kidney,” which is a metaphor for identifying who within the organization contributes to value creation and designing Agile Release Trains (ARTs).
It was hosted at the f/k/a Rally Software headquarters in Boulder, Colorado. Instructors included Dean Leffingwell, Alex Yakyma, Drew Jemilo, and Colin O’Neil. Enterprise representatives included Nokia, McAfee, Mitchell International, EMC, Tendril (the case study in Agile Software Requirements), and Nordstrom. And of course, there were the consultants represented by IconATG, Rally Software, Blue Mercury, and Net Objectives.
In the true spirit of SAFe, the class was full of hands-on experiential exercises, teaming within the class, and knowledge that helped create the evolution and advancement of our traditional Agile mindsets to Lean-Agile mindsets.
There was even a proctored exam on the last day. If memory serves me, there were at least 30 essay questions and about 75 percent of the class graduated as the first SPCs!
I fondly remember chatting with Drew Jemilo, envisioning what SAFe could be in a decade. I can honestly say that the market has validated the need and exceeded all of our visions and expectations. It’s helped tens of thousands of organizations organize and deliver the highest-value products and solutions to their customers and created a powerful career market for lifelong learners, partners, and consultants.
Fast Forward 10 Years
The Framework has never stopped evolving and adapting to the field. Perhaps that’s what makes it unique: continuous value delivery to its customers. As humans, we thrive to evolve and learn, and this enables the sharing of knowledge from people like you.
Some of the latest enhancements include the addition of Principle #10: Organize around value (which was always present, just not as detailed and prevalent) and the seven core competencies of the Lean enterprise, which are crucial to achieving and sustaining your competitive edge.
Today, more than 1,000,000 practitioners and 20,000 enterprises worldwide in nearly every industry trust SAFe. Gartner names SAFe the #1 most considered and adopted framework for scaling Agile. If we were to apply Geoffrey Moore’s technology adoption curve from his book Crossing the Chasm to SAFe, it would most likely be in the early majority, and even in the tornado phase.
If there’s one thing for certain, customers are seeing results, and the Scaled Agile Framework has evolved its initial mission of “Better software and systems make the world a better place.” Today, Version 5 represents the most ambitious expansion of that mission in our history: to enable the business agility that is required for enterprises to compete and thrive in the digital age.
Sincere gratitude to my friend, Alex Yakyma, who helped maintain SAFe history with the visuals and helped refresh my memory of the event.
Learn more about the evolution of the Scaled Agile Framework, follow the SAFe blog, and join us at the 2022 SAFe Summit!
About Jennifer Fawcett
Jennifer is a semi-retired, empathetic Lean and Agile leader, practitioner, coach, speaker, and consultant. As a SAFe Fellow, she contributed to and helped develop SAFe content and courseware. Her passion and focus have been delivering value in the workplace by creating communities and culture through effective communication, product management, product ownership, executive portfolio coaching, and compassionate leadership. She has provided dedicated service in these areas to technology companies for over 35 years.
This post is the first in a series about success patterns for large solutions.
When applying the Scaled Agile Framework® (SAFe®) to large, complex, cyber-physical systems, we have discovered a pattern called solution areas to manage the complexity. A solution area is made up of two to four Agile teams that collaborate daily to solve problems together. A solution area is neither a fixed organizational structure with given roles, events, and artefacts, nor another scaling level between Agile teams and Agile Release Trains (ARTs). Instead, it dynamically adapts to the given work. This solution area pattern is an example of a paradigm shift toward a much more dynamic form of agility. And this shift requires development of organizational skills, as we will explain in this blog series.
Revive the Feature Team Idea
In Agile development, we often speak about feature teams as an important pillar in Agile organization design. The idea of a feature team usually means that a single Agile team has all the skills and tools necessary to produce meaningful end-customer value on its own. This is often hard to achieve when hundreds of engineers must work together to create a complex cyber-physical system.
In such an environment, Agile teams have so many dependencies between them that a single team can hardly produce end-customer value alone. When producing only a portion of an end-customer value, it becomes hard for single Agile teams to pursue meaningful objectives on their own. Changes to their team goals can therefore only be made with the consent of other teams because these changes could potentially impact the other teams’ work.
As a result, a key motivator of why we introduced agility in the first place is lost. We are no longer able to react quickly to learnings and changing requirements, as the effort to recreate alignment between the teams can be considerable. In such an environment the communication efforts are eating up a non-negligible part of the team’s capacity, the result of which is a loss of focus on value and the pivots necessary to achieve it. A typical pattern that arises under these circumstances is ‘spoon-feeding teams.’ For example, in the backlog refinement meetings before Program Increment (PI) Planning, work items are prepared to fit the skill sets of certain teams. The result is that only a specific team can handle a specific work item, thus locking teams into big up-front design.
Solution areas can often solve this problem. Two to four teams collaborating daily, in many cases, can have all the skills and tools necessary to pursue meaningful objectives and produce real end-customer value together. On the one hand, they’re often big enough to take on responsibility for substantial changes to the system, and on the other hand, they are small enough to react quickly to learnings and changing requirements. With the right communication and collaboration structure, solution areas can revive the feature team idea one level higher in the form of feature solution areas.
Self-Organize around the Flow of Value
One of the most important design criteria of a solution area is that the communication and collaboration structure is dynamic and tailored to the objectives of the teams. By introducing solution areas, we don’t want to establish an additional scaling level between Agile teams and ARTs with a set of fixed events, roles, and artefacts. A solution area is like a collection of boundary conditions within which the teams can organize themselves around the flow of value according to their needs. To give you an example, we take a closer look at the synchronization of the events.
Suppose we have four Agile teams in a solution area with the same iteration cadence of two weeks. Every team has an iteration planning at the start of each iteration, daily stand-ups on each working day, and an iteration review and retrospective at the end of the two weeks. A first step in establishing a solution area would be to synchronize each of these team events among all the teams, as illustrated in a 3×3 matrix.
Figure 1: event synchronization matrix
Using this matrix, the teams try to find the leanest synchronization mechanism that fulfills the communication and collaboration needs of the four teams. Let’s take iteration planning as an example. One option could be that the product owners are meeting for 30 minutes in the pre-event of the iteration planning to make sure they all understand the solution area’s iteration goals. After that, each product owner goes back to its respective team for the main event where each team plans its upcoming iteration in the next two hours. After that, all teams meet in a big-room event to align and adjust their iteration plans with all the other teams in the solution area. This post-event could be scheduled for another 90 minutes.
Another option could look completely different regarding the sequence of the sub-events and the timing. For instance, the teams may create a first draft of an iteration plan for themselves within a one-hour time box in the pre-event. Then for the main event, all teams meet for three hours to collaboratively create an iteration plan for the solution area. In the post-event, the scrum masters of the four teams come together to talk about resolving impediments and managing any risks that came up.
After creating an aligned understanding of the communication and collaboration needs of all the teams within the solution area, the ART needs to find a constellation that matches these needs with the least amount of meeting overhead possible. Once found, these synchronization mechanisms are not carved in stone. They can change dynamically according to the objectives of the solution area for a given timebox, like a PI. At first, we usually revisit synchronization mechanisms every PI. Over time, the solution area can change its synchronization within a PI if necessary.
Like the events, we can also synchronize roles, artefacts, and collaborations. For each pillar in the House of Dynamic Agility (see Figure 2), we can use similar matrices to create an aligned understanding of what the specific needs are, and which composition best matches those needs.
For example, the definition of done could be changed or refined to represent the type of work (hardware, software, modeling) or the maturity in the progression toward delivery (regulatory compliance items and reviews).
The House of Dynamic Agility helps leadership master this grammar of transformative co-creation while faced with profound disruption. Moving from an output efficiency-centric focus to an outcome customer-centric operating system requires leadership transformation mastery.
Example system
The solution area for spacecraft navigation systems consists of four Agile teams: LiDAR, RADAR, GPS, and Navigation Control. In the PIs or iterations where the individual types of navigation are focused on hardware upgrades, software algorithm improvements, and other items that are encapsulated within those navigation sub-components, these teams will each send a representative to a post-iteration planning event as their only iteration planning coordination. However, in a PI where they are implementing an anomaly detection feature, they will hold pre-iteration planning coordination with a team representative, and each team will hold an individual iteration planning and one big-room post-iteration event to educate all the participants in the navigation solution area.
The test case and results artefacts they create in earlier iterations are draft artefacts as far as the compliance team is concerned. The integration tests conducted in early iterations use models and are focused on navigation only. As they approach formal verification and validation (V&V), the teams in the solution area will closely collaborate and communicate with the compliance teams and formal V&V testers.
Figure 2: House of Dynamic Agility
Encapsulate Complexity
Another benefit of solution areas is the encapsulation of certain areas of complexity within a large system. Consider a typical cross-functional Agile team. When a software programmer, a database architect, and a tester work together on the same user story, nobody outside this Agile team cares about the dependencies between these team members. In other words, this Agile team encapsulates a part of the complexity of the system.
The same is true for solution areas. As all teams within a solution area are closely synchronized, they also encapsulate a certain part of the complexity, usually a larger part compared to an Agile team, which is aligned to a complex component of the large system. The dependencies between the teams and team members within the solution area are a concern within the solution area only.
Looking at a solution area board, only the dependencies below the thick blue line are of interest to other solution areas, ARTs, solution trains, or suppliers. The dependencies above the thick blue line are managed by the teams within the solution area itself.
Figure 3: solution area board
This also leads to an important design principle: there should be more dependencies between teams within a solution area than dependencies between the solution area and the outside world. The stronger the collaboration within a solution area, the more cross-functional teams become, which then creates better decision-making.
Maybe the most important aspect of encapsulating complexity is the switch from linear or orderly value streams to unordered or “messy” value streams. Our characterization of “messy” value streams as an enabler for creativity is inspired by Tim Harford’s book: Messy: How to Be Creative and Resilient in a Tidy-Minded World. Within a single Agile team, we usually don’t have clearly ordered value streams. People collaborate with whomever on whatever makes the most sense at that point in time. It could be something planned or completely unforeseen. It could contribute to an iteration goal or a PI objective. Or it could be something that deviates from any planned work, such as investigating a new path or following a new learning.
Especially when creating something new, this creative freedom of a messy value stream can lead to better, high-quality products. With the right synchronization mechanisms tailored to the needs of individual solution areas, the ability to react to unforeseen changes in development can be fast enough to support messy value streams. This establishes a creative environment like a single Agile team at one level higher.
React Quickly to Changing Value Stream Networks
Forming solution areas around architectural domains helps create better solutions, faster. But what about cross-domain problems? For many large system problems, several domains must work together to come up with satisfying results. These problem spaces often show up like bubbles on top of the architectural layer, meandering around for a while whilst people are working on certain aspects before they are completely solved and vanish. Sometimes problem spaces can be planned for; sometimes they show up completely unforeseen.
With solution areas already in place around architectural domains, a next step could be forming new, cross-domain solution areas which exist only if necessary to address the problem space. These new cross-domain solution areas bring together people or complete Agile teams from different solution areas. They are only temporary, existing from one iteration to several PIs.
Ramping up cross-domain solution areas can be seen as an additional organizational skill on top of the organizational skill of synchronizing Agile teams within a domain-aligned solution area. Management should not decide the structure of new solution areas; the people closest to the problem should. Management only sets the boundary conditions for the self-organization of the people doing the work.
The goal is to enable an organization to ramp up new organizational structures quickly when needed and ramp them down the moment a problem is solved so that organizational structures can flow around architectural needs.
Figure 4: domains, problem spaces, and solution areas
Find the Sweet Spot for Organizational Learning
Organizational skills that facilitate dynamic agility require training in the form of a focused effort to help parts of the organization identify options, build new structures, and abandon them as soon as the problems are solved.
Like with a professional sports team, this approach needs qualified coaches and an aligned vision of how to play this Agile game. The vision needs to be broken down into moves that team members can master, one move at a time.
A successful approach relies on finding the right level for this training. Single Agile teams are often too small to react on their own in a significant way to changes in the complex value stream networks in which they participate. Yet, ARTs are often too large to change their structures frequently and fast enough. Solution areas have the right size and focus to react quickly and change structures around the flow of value in a meaningful way. The solution area construct is often the sweet spot for organizational learning, replacing organizational structures with organizational skills.
Solution areas are given the language and technology to facilitate the inter-relationship of the system elements (for example, leadership, employees, and customers) as part of the whole ecosystem to which they belong.
Find the Minimum Viable Structure
When striving to build large systems in an Agile way, adding scaling levels on top of each other isn’t helpful. From our experience, the core proposition of the organizational architecture of large systems must be dynamic and tailored to the needs. Stated another way, we must descale before we scale up. We want to have the minimum viable organizational architecture— the bare minimum to satisfy the cognitive, communication, and collaboration demands of the teams involved.
This efficiency goal is not achievable by following a set of fixed roles, events, and artefacts, but only by enabling the teams to dynamically and frequently change their communication and collaboration structures according to the objectives on which they focus. This dynamic agility approach can reduce the impediments to the flow of value, leaving room for innovation and learning when scaling up to large, complex system delivery.
Dr. Wolfgang Brandhuber has been a Scrum Developer, Product Owner, Scrum Master, Chief Scrum Master, and Agile Head Coach in various Agile environments. His passion is large solutions. Since the advent of the large solution level in the Scaled Agile Framework in 2016, he has set up and helped solution trains improve their complex systems. During his 18 years as a professional consultant, he worked over 16 of those in the Agile world and more than nine years with SAFe. Among other certifications, he is a certified SAFe® Program Consultant Trainer (SPCT), a Kanban University Trainer (AKT), and an Agility Health Trainer (AHT).
About Cindy VanEpps, Project & Team, Inc.
From crafting space shuttle flight design and mission control software at Johnson Space Center to roles including software developer, technical lead, development manager, consultant, and solution developer, Cindy has an extensive repertoire of skills and experience. As a SAFe® Program Consultant Trainer (SPCT) and Model-based Systems Engineering (MBSE) expert, her thought leadership, teaching, and consulting rely on pragmatism in the application of Agile practices.
About Malte Kumlehn, Project & Team, Inc.
Malte helps deliver complex ecosystems, people, Cloud, AI, and data-powered digital transformations toward business agility. He pioneers intelligent operating models for portfolios with large solutions as a SAFe® Fellow, advisory board member, and executive advisor in this field. He guides executives in developing the most challenging competencies that allow them to deliver breakthrough results through Lean-Agile at scale. His experience has been published by Accenture, Gartner, and the Swiss Association for Quality over the last ten years.
Note: This is the third post in the Practice Makes Permanent series. Read the first post here and the second post here. You can watch my webinar on PI Planning here.
Is your SAFe® implementation slowing? Has the energy and enthusiasm faded and it feels like just one more process change? Maybe you’re just not seeing the value you expected? That’s OK because PI Planning presents significant opportunities for your relentless improvement of the SAFe journey.
If you’ve read the previous posts in this series, you know that the right kind of SAFe practice doesn’t make perfect, it makes permanent. And you know that using creative tension will help you find the right outlook to discover new opportunities and foster relentless improvement. The reality is that many Agile Release Trains (ARTs) have a distorted view of PI Planning—they see it as a readout of the already created plan or a time to direct teams toward a plan rather than the discovery session it’s intended to be. This makes it a great place to get your implementation back on track. PI Planning is an opportunity to discover the plan for the next PI. Discovery is exciting, it’s engaging, and it’s about learning.
Through my years of teaching and implementing SAFe, I’ve identified key practices to help organizations successfully discover a plan for the upcoming PI. My goal in providing these tips and techniques is to give you practical ideas on how to revolutionize your PI Planning and improve the quality of your plans.
Consider these key practices to make PI Planning a discovery session:
Breadth vs. depth planning
Good objectives start early
Iteration plans from PI Planning are “what if?” scenarios
Raise the levels evenly
Preconceived is pre-committed—limit pre-PI Planning
Breadth vs. Depth Planning
During PI Planning, the Agile teams are instrumental in converting the ART vision and roadmap into team-committed objectives while discovering the risks, dependencies, and delivery goals for the PI.
The anti-pattern
A very common anti-pattern in PI Planning is when teams focus on one iteration at a time, attempting to create a solid plan for iteration one, followed by a deep dive in iteration two, and so on. This is dangerous because we’re not seeing the big picture of the whole PI. And often we get to the draft plan review, and the teams don’t have a high-level, end-to-end plan, which is critical for the management (adjustment) review and problem-solving activity.
Additionally, because teams have gone iteration by iteration, concentrating on creating and loading stories, they haven’t collaborated sufficiently on with other teams on dependencies. This can potentially lead to radical plan changes during team breakouts on day two.
Implement breadth vs. depth
This is where breadth vs depth comes in. Encourage your teams to think across the whole PI and create a very high-level plan within the first 60–90 minutes of the first breakout session. This will include initial starter objectives, the discovery of some initial dependencies on other teams, high-level goals for each iteration, and some initial stories (perhaps slotted into an iteration). These activities give teams a broad, overall approach.
Now, they can use the remaining time in the breakout to improve the depth by:
Discovering more stories
Identifying more dependencies
Refining objectives
Identifying and (perhaps) mitigating more risks
This breadth vs. depth strategy ensures that there’s always a draft plan to review and helps teams align on the approach and effort distribution.
Here’s a quick recap of the key principles of breadth vs. depth:
Start with a high-level, end-to-end plan that’s full of holes.
As time permits, go back and fill in those gaps.
Focus on “based on what we currently know, this is our plan. However, we know we have more to learn to fill in some gaps.”
Raise the water level evenly. Create some story placeholders, which will generate some objectives, which will raise some dependencies, which will identify more stories, which will update objectives, and so on.
Apply SAFe® Principle #3: Assume variability; preserve options. Start with minimal constraints and a high-level approach and add details as they emerge.
Good Objectives Start Early
Team objectives are one of the key outputs of the planning effort. Objectives are a team’s opportunity to say:
“Hey, ART leadership, we saw the vision, we saw the roadmap from the top x features. Here’s our contribution to the success of the ART for this PI.”
This is a powerful opportunity to engage SAFe Principle #8 and SAFe Principle #9 and is a critical component to ensuring alignment.
Many teams struggle with understanding objectives because they’re not used to being asked, “What can you contribute to our success?” Instead, they’re used to being told “this is what needs to be done.” I like to explain objectives with an analogy.
Team objectives
Imagine you’ve just read a really powerful, thought-changing book (such as Donald Reinertsen’s Principles of Product Development Flow). Most likely you’ve read the book chapter by chapter. You want to share the power of that book with your friend, and you’ll probably share highlights and key areas and concepts from your perspective. Now, another friend reads the same book and shares their key takeaways from their perspective. While there may be similarities in key concepts (for example, Economic Sequencing) each perspective may pick up on different areas and ideas that were key to them but that maybe didn’t stand out to you.
The chapters in the book are the features. All the teams read the features and come away with their key areas and contributions. These are the team objectives. Some teams may have shared contributions across the ART (Program Objectives), but many will have specific contributions unique to their own team (Team Objectives).
Start early, iterate often
So, how do you achieve these powerful objectives within PI Planning? That’s where the phrase “good objectives start early” comes in. Objectives should start as early thoughts and concepts and grow in clarity and alignment as the breakout continues.
These are the key principles to successfully writing objectives:
Start writing objectives early in the first breakout.
Don’t wait until you have ‘perfect’ objectives; perfect is the enemy of good.
As you learn more about the plan during the breakout conversations, potential objectives will emerge. Write these down, no matter how incomplete they are.
As you learn more about the objective through further planning-fueled learning, update the objectives.
Don’t try to start with SMART objectives, work toward them.
Iteration Plans from PI Planning Are What-If Scenarios
A common issue that limits the self-organization aspect of SAFe Agile teams is the mistaken belief that teams are creating iteration plans that must be locked in and committed to. This is a highly critical point: teams do not commit to iteration plans in PI Planning. They’re committing to the objectives they discover, and to the Program Board, which identifies when they believe they can deliver on the features and what dependencies are needed to deliver. When teams have the false belief that they’re going to be held accountable for plans for four iterations in sequence, they become nervous, realizing they can’t really know exactly what will be needed for each iteration. They believe they’re being held to a mini-waterfall approach. Actually, the opposite is true.
We ask teams to create iteration plans so that they can discover the objectives they want to commit to, discover the significant dependencies needed to deliver the features they pull in and discover the risks that may threaten the plan. The plan they create is one of many possible ways they can deliver, and many of the details of the actual plan will surface as they execute that plan. In my experience, the specific iteration plans the teams create are about 60-percent accurate. As long as we have the significant dependencies and risks identified, that level of accuracy is good enough to get started.
Key principles around the what-if scenario approach:
Teams do not commit to iteration plans. They commit to objectives and the Program Board’s dependencies and Feature deliveries.
Teams create iteration plans to unearth dependencies, discover objectives, and learn how to deliver to the business.
The iteration plans will almost certainly change as we iterate through the Program Increment. Understanding that we are only identifying one of many possible scenarios to deliver on these objectives helps the teams focus on what’s important.
Raise the Levels Evenly
Closely associated with the breadth vs. depth concept is ensuring you have a good balance of focus on each component of the Draft Plan Review. Following SAFe Principle #4, we want to shorten our Plan-Do-Check-Adjust (PDCA) cycles to increase the pace of learning. If you think of each key area of focus in the team breakout, we have:
Creating, sizing, prioritizing user stories and enabler stories
Identifying and improving team objectives
Identifying and attempting to mitigate risks
Discovering, discussing, and gaining commitment to cross-team dependencies
Updating the Program Board as we discover new feature delivery and dependency aspects in the emerging plan
Consider each of these areas as buckets to fill. We don’t want to fill one bucket to the top and then go to the next. Instead, we want to evenly bring up the level on all buckets together. That means we want the teams to generate some stories, which can lead to updated objectives, which can lead to new risks identified or mitigated, leading to new commitments with other teams, and leading to updates to the Program Board. This order is not rigid, there’s nothing wrong with discovering a dependency, adding some stories to cover this dependency, and then updating Program Board. The idea is to make sure that we are keeping the levels (amount of recorded information) approximately even across all the buckets.
These are the key principles to raising the levels evenly:
Don’t try to create a full iteration-by-iteration plan too early.
Use the energy and knowledge from adding to one bucket to add to the next bucket.
At regular intervals, step back and review the levels in each bucket. Are these relatively evenly filled? If not, do we need to revert to focus on a particular bucket?
At key points, review the entire plan we have created so far. Do we see major gaps? Dangerous assumptions? Note: a great time to do this is about five minutes before the next Scrum of Scrums team breakout. It provides a really clear view of the current progress that will help us identify any systemic issues in our planning process.
Preconceived Is Precommitted—Limit Pre-PI Planning
Before we start PI Planning, we need the right level of readiness. But too much can lose the discovery aspect of PI Planning. Finding that balance is a learning journey, but there are key elements to balance.
Too much pre-PI Planning:
Takes away from the current PI effort. The focus should be on this PI’s objectives, not pre-planning for the next.
Locks into a plan that is not well-informed. PI Planning is about learning, not perfecting. The best objectives come from shared learning during PI Planning.
Damages the team-of-teams culture in the ART.
Too little pre-PI Planning:
Leaves the teams anxious
Can waste time in PI Planning trying to answer foundational questions
The right balance of PI Planning:
Allows teams to ask intelligent questions during the morning briefings. The test I apply is to verify: are the questions probing and refining (good) or are they high level and more about initial alignment (not so good).
Ensures we have the right people in the room. For this PI’s features, we may need other shared services and assistance. Knowing this in advance helps us extend invites to the right people.
Sets the stage for PDCA-based learning cycles during PI Planning. When teams come into PI Planning thinking they already have the right plan, it leads to a fixed mindset for the next PI, which blocks the true discovery needed. We want the team of teams (ART) to iterate through these PDCA cycles together as they discover the plan.
I use a very simple approach—called the five-sticky rule—to help teams understand a good starting point for the level of pre-planning needed. Each team is encouraged to bring five sticky notes into PI Planning that represent potential stories. This requires the team to do enough discovery around the features, vision, and other elements needed in the next PI but keeps them from creating a deep-dive plan that loses the discovery aspect. Please note that the five-sticky rule is more of a guideline than a rule and can be adjusted as needed.
These are the key principles to finding a balance of pre-planning:
Prepare to create the plan, don’t pre-create the plan
Look for intelligent, informed questions during the briefings
Beware of a fixed mindset view of the plan coming into PI Planning
PI Planning is one of the Ten Critical Success Factors to achieve transformational progress with SAFe. By applying the above ideas, you can make it the dynamic, engaging, energetic event it’s intended to be. So, go make your PI Planning a discovery session!
Check back soon for the next post in the series.
About Dwayne Stroman
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
How to use the gap between where you are and where you want to be
This post is part of the ongoing Practice Makes Permanent blog series. Read the first post here.
OK, so your Lean-Agile transformation is stalling. It’s not delivering the increased value and reduced delivery times you expected. Your teams are struggling and perhaps updating their resumes. You thought that implementing the Scaled Agile Framework® (SAFe®) would bring you these outcomes, but you’ve discovered you’re not using all Ten Critical Success Factors of SAFe. Perhaps you’ve discovered that you’re not actually implementing SAFe correctly as you intended, which means you’re probably not gaining the full value of what the Framework has to offer. The key to taking full advantage of this realization is to be encouraged rather than discouraged. We can’t improve until we see the improvements that are needed. The purpose of this article is to help you see that these discoveries should be cause for celebration, not concern.
One of my favorite books (and authors) is Peter Senge’s The Fifth Discipline. In his book, Peter describes the concept of creative tension as ”the tension between vision and reality.” It’s the concept of discovering the gap between where you are and where you want to be and using that gap as energy to make improvements. Think of it as a transformational snowball effect.
SAFe guidance depicts the perfect scenario where an organization exemplifies all seven core competencies, delivering high quality and accurate value to customers, and having the kind of culture and work environment that makes it a great place to work. Then we look at the current reality and realize we have a long way to go to reach this nirvana state of business agility.
Sometimes that gap seems insurmountable, unachievable, and perhaps just unrealistic. As we identify that first improvement opportunity and implement that first improvement effort, we start to see some excitement and engagement. We’re still a long way from that nirvana view, but we’re starting to make progress. And that creates more energy for the next effort. So, we take on the next improvement effort, and there seems to be just a bit more engagement and hope that we can move forward. And that’s where we start to see the snowball effect of relentless improvement.
The snowball effect.
For each improvement we make, we gain more energy, engagement, and willingness to change. And we start to go faster. And faster. And faster. And now, that relentless improvement pillar seems to make more sense, and in fact, becomes part of our DNA. As Peter Senge stated, “The most effective people are those who can ‘hold’ their vision while remaining committed to seeing current reality clearly.”
Positive change is contagious. It brings excitement and hope to the organization. That energy must start somewhere. So, as Taichi Ohno said, “If you are going to do Kaizen continuously … you’ve got to assume that things are a mess. Too many people just assume that things are all right the way they are … If you assume that things are all right the way they are, you can’t do Kaizen. So, change something!”
My point is to change something with a huge grin on your face because you can see the snowball effect of creative tension pulling you upward.
A team celebrating its small wins.
So, when you see that gap between your current reality and where you want to be, you should view it as an opportunity, not a negative situation. In other words, you should view every improvement opportunity with excitement and anticipation of where you can go next on the journey toward business agility.
As change agents, we’ve learned that empathy along the transformation journey is vital. We know how hard it is, so we fully understand why you skipped some of the steps. But now is the time to restart or renew that journey. In subsequent posts, we will talk about specific activities and components we can use the creative tension approach to jump-start a Lean-Agile transformation. The goal of this series is to help you find the next opportunity to accelerate that snowball effect in your transformation.
Check back soon for the next post in the series.
About Dwayne Stroman
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
A big part of my personal life revolves around motorcycles, specifically road racing and coaching. When I’m working with new racers or track riders who want to improve their skills, the first thing I do is ask them to complete this sentence: “Practice makes _____.” Almost everyone says “perfect!” But usually, the opposite is true. When racers go out on the track and continue to repeat bad habits, such as not moving their eyes down-track or using poor body position, they simply cement the wrong technique, which is more difficult to correct later. I always teach riders to focus on learning the basics and build on these good techniques until they become permanent. We all start with the belief that practice makes perfect. However, if you practice the wrong things, the only thing you perfect is the wrong approach. (Note: I want to thank Nick Ienatsch from the Yamaha Champions Riding School (YCRS) for helping me see the importance of learning the right skills before starting to practice. Working with Nick and the crew at YCRS and ChampSchool taught me so much about the importance of getting the basics right.)
The author coaches the basics in an off-track drill.
Switching sports metaphors, a favorite phrase from football coaches (Marv Levy may have been the first to use this) is to “learn how to do it right and then practice it until you never get it wrong.” That’s how we bake in the right techniques, and where practice makes permanent is our ally.
When implementing SAFe®, it’s common to bring in old habits from your organization’s history. It’s hard to break free of these past practices but it’s even more difficult to change them once they’ve been brought into the transformation effort. There are many common anti-patterns that organizations practice and make permanent, including:
Multiple Program Backlogs (whether real or virtual) make it difficult for the teams or ART to focus on the most important thing to work on; this damages Lean flow due to context switching.
Leadership believing that their job is to direct work, which is in direct opposition to SAFe Principle 8 (unlock intrinsic motivation) and SAFe Principle 9 (decentralize decision-making).
Not using the IP iteration for its vital purpose to be a buffer for capacity and to support ongoing innovation, improvement, and synchronized planning.
Using PI planning as a readout of assigned plans, rather than allowing the teams to use team breakouts to discover the best plan to meet business needs.
Objectives given to the teams rather than teams creating their own objectives. When teams review the vision and roadmap and then create their own objectives, they gain engagement and alignment with business and Product Management to demonstrate they understand the value needed.
A common issue we see is organizations treating SAFe as a buffet where you can pick and choose what you implement and what you don’t. While SAFe is highly configurable and is not at all prescriptive, there are key elements that you must implement for real success. These 10 critical success factors are the basic components that you learn and practice until you never get them wrong.
This doesn’t mean that you must be perfect to start. Learning to implement SAFe correctly is just like learning to ride both fast and safe. You learn the proper techniques and continue to inspect and adapt until you get it right, then practice these techniques until they become instinctive. That’s when the speed comes. The same concept applies to your SAFe implementation—learn the 10 critical success factors and practice them until they become instinctive. You will make mistakes along the way because getting these factors right takes time and effort. But if you continue to focus on these basics, they become part of the culture and the norm for your organization. That’s when you experience the true value of a SAFe implementation.
Practice Makes Permanent Blog Series
In this blog series, I aim to share my experiences from the field in helping organizations master and apply good, basic, Lean-Agile and SAFe practices to promote successful SAFe implementation.
Upcoming topics I plan to cover include PI planning, the Program Backlog, and SAFe roles. My hope is that as part of this effort, you will be able to achieve business agility through the Lean-Agile mindset.
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
Globalization is an important growth strategy for Scaled Agile. Localization of SAFe content enables our customers worldwide to participate and learn in their own native language. And it helps drive the adoption of SAFe across international markets.
We need several key ingredients to create a great global product. One of them is people. Since I started working at Scaled Agile, one of the most rewarding experiences was building a global SAFe In-country Review (ICR) team comprised of SAF SAFe experts —known as SPCs and SPCTs—from around the globe. All of them are highly experienced Agile coaches and transformation leaders who are changing the way people work in their respective countries. I’ve had the utmost pleasure of working closely with this team and I can tell you that they are fantastic people!
At Scaled Agile, translation quality, including that of our glossary, is critical. We don’t simply translate a term. We make sure every term has been discussed and thoroughly vetted by our passionate ICR team. Does the term or concept exist in the target language? If the concept can be translated in multiple ways, which one is most appropriate given the context? Do we use the traditional translation of the term or the anglicized version? Does the transliteration make sense instead? These are just a few examples of the questions that our ICR team addresses on a regular basis.
After all, the glossary is an integral part of the learning experience. And we need to ensure that SAFe content is well-translated and of high quality. Thanks to our ICR team’s effort, the SAFe glossary is now available in 13 languages.
The holiday season is a perfect time for reflection. I’d like to take a moment to recognize the contribution of the ICR team and properly thank everyone who contributed. The list below includes past and current ICR team members (listed in alphabetical order by the first name). These individuals went above and beyond to contribute to the SAFe community by sharing their knowledge and devoting their time. They’re helping to make SAFe more accessible to learners worldwide.
I’d like to say a heartfelt thank you to our special ICR team because we couldn’t have done it without you! I look forward to working with everyone in the new year as we will continue to update the SAFe glossary and focus on courseware translations.
Wherever you are, whatever you are celebrating, I wish everyone a healthy, happy holiday season!
Interested in becoming an ICR? Please click here to learn more.
About Yuka Kurihara
Yuka is Director of Globalization Services at Scaled Agile, Inc. She has 20+ years of experience building corporate globalization strategies and leading localization technology and operations in enterprises of all sizes. Connect with Yuka on LinkedIn.
The title of my post may read like acronym soup but all of these concepts play a critical role in SAFe, and understanding how they’re connected is important for successful SAFe implementation. After exploring some connections, I will suggest some actions you can take while designing, evaluating, or accelerating your implementation.
KPIs and OKRs
The SAFe Value Stream KPIs article describes Key Performance Indicators (KPIs) as “the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes.”
That includes:
Health of day-to-day performance
Work to create sustainable change in performance
Objectives and Key Results (OKRs) are meant to be about driving and evaluating change rather than maintaining the status quo. Therefore, they are a special kind of KPI. Objectives point towards the desired state. Key results measure progress towards that desired state.
But how do these different concepts map to SAFe’s Operational Value Streams (OVSs) and Development Value Streams (DVSs)? And why should you care?
Changing and Improving the Operation
Like Strategic Themes, most OKRs point to the desired change in business performance. These OKRs would be the ones that company leadership cares about. And they would be advanced through the efforts of a DVS (or multiple ones).
For example, if the business wants to move to a subscription/SaaS model, that’s a change in the operating model—a change in how the OVS looks and operates. That change is supported by the development of new systems and capabilities, which is work that will be accomplished by a DVS (or multiple ones).
This view enables us to recognize the wider application of the DVS concept that we talk about in SAFe 5. Business agility means using Agile and SAFe constructs to develop any sort of changing the business needs, regardless of whether that change includes IT or technology.
Whenever we are trying to change our operation, there’s a question about how much variability we’re expecting around this change. Is there more known than the unknown? Or vice versa? Are we making this change in an environment of volatility, uncertainty, complexity, and ambiguity? If yes, then using a DVS construct that employs empiricism to seek the right answers to how to achieve the OKR is essential, regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from an Agile and SAFe DVS approach.
These OKRs would then find themselves elaborated and advanced through the backlogs and backlog items in the various ARTs and teams involved in this OKR.
In some cases, an OKR would drive the creation of a focused DVS. This is the culmination of the Organize around Value Lean-Agile SAFe Principle. This is why Strategic Themes and OKRs should be an important consideration when trying to identify value streams and ARTs (in the Value Stream and ART identification workshop). And a significant new theme/OKR should trigger some rethinking of whether the current DVS network is optimally organized to support the new value creation goals set by the organization.
Maintaining the Health of the Operation
As mentioned earlier, maintaining the health of the operation is also tracked through KPIs. Here we expect stability and predictability in performance. It’s crucial work but it’s not what OKRs or Strategic Themes are about.
This work can be simple, complex, or even chaotic depending on the domain. The desire of any organization is to bring its operation under as much control as possible and minimize variability as it makes sense in the business domain. What this means is that in many cases, we don’t need Agile and empiricism in order to actually run the operation. Lean and flow techniques can still be useful to create sustainable, healthy flow (see more in the Organizational Agility competency).
Whenever people working in the OVS switch to improving the OVS (or in other words working on versus in the operation), they are, in essence, moving over implicitly to a DVS.
Some organizations make this duality explicit by creating a DVS that involves a combination of people who spend some of their time in the OVS and some of their time working on it together with people who are focused on working on the OVS. For example, an orthopedic clinic network in New England created a DVS comprising clinicians, doctors, PAs, and billing managers (that work the majority of their time in the OVS) together with IT professionals. Major improvements to the OVS happen in this DVS.
Improving the Development Value Stream
The DVS needs to relentlessly improve and learn as well. Examples of OKRs in this space could be: improving time-to-market, as measured by improved flow time or by improving the predictability of business value delivered, as measured by improved flow predictability. It could also be: organize around value, measured by the number of dependencies and the reduction in the number of Solution Trains required.
This is also where the SAFe transformation or Agile journey lives. There are ways to improve DVSs or the overall network of DVSs, creating a much-improved business capability to enhance its operation and advance business OKRs.
Implementing OKRs in this space relates more to enablers in the SAFe backlogs than to features or capabilities. Again, these OKRs change the way the DVS works.
Running the Development Value Stream
Similar metrics can be used as KPIs that help maintain the health of the DVS on an ongoing basis. For example, if technical debt is currently under control, a KPI monitoring it might suffice and hopefully will help avoid a major technical debt crisis. If we weren’t diligent enough to avoid the crisis, an objective could be put in place to significantly reduce the amount of technical debt. Achieving a certain threshold for a tech debt KPI could serve as a key result (KR) for this objective. Once it’s achieved, we might leave the tech debt KPI in place to maintain health.
It’s like continuing to monitor your weight after you’ve gone on a serious diet. During the diet, you have an objective of achieving a healthy weight with a KR tracking BMI and aiming to get below 25. After achieving your objective, you continue to track your BMI as a KPI.
Taking Action to Advance Your Implementation Using OKRs
In this blog post, we explored the relationship between operational and development value streams and the Strategic Themes and OKRs. We’ve seen OVS KPIs and OKRs as well as DVS OKRs and KPIs.
A key step in accelerating business agility is to continually assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment.
Start by reviewing your OKRs and KPIs and categorize them according to OVS/DVS/Change/Run.
You can use the matrix below.
If you find some OKRs on the left side of the matrix, it’s time to rethink.
Run-focused OKRs should actually be described as KPIs. Discuss the difference and whether you’re actually looking for meaningful change to these KPIs (in which case it really can be an OKR—but make sure it is well described as one) or are happy to just maintain a healthy status quo.
You can then consider your DVS network/ART/team topology. Is it sufficiently aligned with your OKRs/KPIs? Are there interesting opportunities to reorganize around value?
This process can also be used in a Value Stream Identification workshop for the initial design of the implementation or whenever you want to inspect and adapt it.
Find me on LinkedIn to learn more about making these connections in your SAFe context via an OKR workshop.
About Yuval Yeret
Yuval is a SAFe Fellow and 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. Find Yuval on LinkedIn.
How the Business Agility Value Stream will prepare you to win in the post-digital economy with AI, big data, and the cloud.
Introduction
At the 2021 Global SAFe Summit, Dean Leffingwell presented the idea that we are at the threshold of a new technological revolution. A post-digital economy that’s being driven by the adoption of ABC: artificial intelligence (AI), big data, and the cloud. Dean further explained how the Business Agility Value Stream (BAVS) creates a system that will allow businesses to rapidly react to the insights provided by ABC.
If you’re anything like me, listening to Dean’s talk generated many different ideas. In fact, several weeks passed before I went back and re-listened to the keynote to identify the core intent of the talk.
Those insights are what I’m sharing with you today: an understanding of the BAVS and how the concepts of ABC fit into the future of organizations using SAFe.
The Business Agility Value Stream
The value stream construct has been discussed in every version of SAFe dating back to SAFe 2.5 (2013). However, the conversation wasn’t top-of-mind until SAFe5 and the introduction of SAFe Lean-Agile Principle #10, Organize Around Value.
Now, and rightfully so, every organization that seeks to embrace SAFe is challenged to identify and optimize how value reaches the customer via their operational value streams (OVSs). We then challenge organizations to go a step further and optimize the relationship between the OVS, its supporting development value streams (DVSs), and the Agile Release Trains (ARTs) that realize them by considering complexities of the business architecture, technical architecture, and how the people who support the systems are dispersed.
We do our best to support SAFe enterprises and SPCs in this difficult conversation with the Value Stream and ART Identification workshop, and the newly released Value Stream Mapping workshop (both are available on the SAFe Community Platform). Even with the assets and expert consulting available, changing and optimizing the system to focus on outcomes instead of outputs is no small undertaking. And for what purpose?
Though optimizing these value streams is a goal, we must also consider why optimized value streams are so important and what to do with them.
Enter the BAVS.
Powered by optimized OVSs and DVSs, the BAVS puts those charged with strategy in a position to:
Sense market opportunities
Formulate a hypothesis to exploit the identified opportunity via the Lean Business Case
Gain alignment and approval to pursue an MVP through Lean Portfolio Management (LPM)
Organize around value by introducing the MVP to existing ARTs (or if needed, standing up a new ART)
Leverage the tools of Agile product management and design thinking
Develop a customer-focused solution
Deliver the MVP in 2–6 months via the continuous delivery pipeline
Monitor the solution in LPM to determine if the hypothesis holds true or needs to be reconsidered
Continue to deliver value and learn until the business opportunity has been fully leveraged
What is ABC?
With the system optimized and the BAVS in place, you are likely now left wondering how the enterprise is expected to sense emerging business opportunities. Though expertise and experience continue to play a role in how opportunities are addressed, we can no longer afford to guess where the next opportunity lies. Partly because an uninformed guess is full of risk to revenue, team stability, and market reputation, but mostly because uninformed guesses could rapidly destroy a business. In the post-digital economy, the amount of time required for an organization to recognize an opportunity, ruminate about how to address it, and then put the plan into action is far greater than the window of opportunity will remain open.
This is where ABC comes in—its three elements power the modern decision engine.
AI
There are bound to be some really cool applications for AI, but I suspect that the majority will be less dramatic than its portrayal in Hollywood. For many of our organizations, AI will be put to use to address customer service, mitigate fraud and other risks, optimize development processes, and identify emerging trends in data. In terms of the BAVS, when leveraged, AI will serve as the trigger that identifies market opportunities and threats that the BAVS will respond to through business insights, operational efficiencies, and intelligent customer solutions.
Big Data
For AI to work effectively, the algorithms require access to large amounts of data—the more the better. Fortunately, many companies have decades worth of historical data and are collecting more each day. The problem that many organizations are addressing is how to pool that data into an easily accessible common format, but that is a conversation for another day.
Data is the answer. And for it to power organizations, it cannot be bound by organizational politics or structures. The key to enterprise success in the next digital age is in the organization’s data. We only need to ask the right questions of the data.
Cloud
With so much data and so much analysis required to make sense of it all, we are fortunate to live in the age of infinitely scalable infrastructure via the cloud. Imagine 15 years ago the amount of work required to bring 100 new CPUs online to address a complex problem. An undertaking of this magnitude would have required new servers, racks, bandwidth, electricity, and a facility to store the new hardware. It would have taken months to a year or longer to bring online.
Today, we can scale our infrastructure to nearly infinite capacity with the touch of a button, and descale it nearly as fast. We have the capacity (cloud), we have the resources (data), and we have the capability (AI) to win in the post-digital economy. The only thing that stands in the way of exploiting those elements is changing our system of work to keep pace.
What Will You Do with ABC?
The purpose of the Scaled Agile Framework is to help organizations thrive in this technological revolution and those that are sure to come. The mission of SAFe is to work differently and build the future. The path to achieving our mission and purpose is constantly evolving with the world of business and technology. Though we don’t claim to have all of the answers, we’re confident that we can provide the tools and intent to help organizations solve for their own unique context.
The BAVS is the latest evolution of a perspective that started nearly eight years ago with improving the delivery of technology to the enterprise. We’re excited to see what organizations do with ABC and how their BAVS delivers value and change to the world. Especially as all we do becomes more interconnected and the true possibilities of the near-limitless potential of people become more apparent.
About Adam Mattis
Adam Mattis is a SAFe Fellow and 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.
“Working for an organization that practices SAFe means employees can be confident that their code will get to production and that their SAFe training will secure them transportable skills that add value to their career paths.”
Console Connect needed to deliver positive and on-time outcomes for its customers and partners and amplify its ability to attract talented technologists to the business.
Impact
Attracted and trained new staff in a competitive market
Improved business goal setting and ability to measure business value
Reduced the number of lower business value objectives to allow time for innovation
Quality
“SAFe brought a much-needed approach to scaling Agile and systems thinking that was critical to an organization of our size and complexity.”
—Brent Weaver, Director of Systems Implementation, CMS
CMS was charged with improving systems thinking within a deeply ingrained Waterfall culture. They sought a solution that could scale within the complex organization of the Center of Clinical Standards and Quality (CCSQ) and deliver on citizen expectations.
Impact
Improved quality – 55% decrease in help desk tickets from hospitals, demonstrating a direct impact on customer satisfaction
Budget shift to modernization versus maintenance – Now 60% of the budget goes toward innovation for the system, helping the agency deliver on citizen expectations
Happier employees – Surveys conducted before and after SAFe show a 27% increase in employee satisfaction
Time-to-market
30%
improvement in average process time for developing features.
Handelsbanken, a Swedish bank known for its innovative practices, wanted to cut its time to market and improve its customer offerings. They needed a collaborative partner to contribute to those goals. The bank explored SAFe and gained trust knowing that several large companies and banks in its region had found success with it.
Impact
With SAFe, Handelsbanken achieved its goal of enabling automated decisions for mortgages sooner than expected. The structure of the framework helped them think big, focusing on flow and results.
Six years ago, Mercedes-Benz had one or two product roll-outs a year in just a couple of markets. In 2022, they were able to introduce roughly 40 products in 34 markets. Moving away from Waterfall methods and adopting SAFe, they were able to launch better technology, better operating systems, AI and face recognition, integrate different data sources, and utilize better risk models.
Impact
SAFe allowed Mercedes-Benz to achieve the shift from hardware to software, master the electrification of vehicles, meet requirements for zero emission, and adapt to environmental, geopolitical, and consumer demands.
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.
