Kaiser Permanente builds the future of healthcare with SAFe

Reimagined technology and clinical workflows transform home care for members

Share:

Kaiser Permanente is one of America’s leading not-for-profit health care providers and not-for-profit health plans serving 12.5 million members.

Driven by new technologies and evolving expectations for patient convenience, the golden age of care at home may be just around the corner. Reimagined technology and clinical workflows will transform coordinated and patient-centered care for Kaiser Permanente members in the comfort of their own homes.

In this video, Agile coach Steven Archer and IT leader Kari Powelson share their SAFe journey and the “ART” of making SAFe work at KP. They will describe how their Care Delivery Technology Services and Clinical Operations development teams came together to build new software and workflows and set out to prove that KP Care at Home is the future of healthcare and that it can be a great experience for members and clinicians alike.

Presented at the 2021 Global SAFe Summit, October 2021 by:

  • Kari Powelson, Executive Director IT Leader Home Care /Kaiser Permanente
  • Steven Archer, Principal Agile Coach /Kaiser Permanente

Back to: Customer Stories

Next: FedEx Customer Story

How We Used DevOps to Rework Our DevOps Course

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

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

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

The SAFe Approach to DevOps

How We Used DevOps

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

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

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

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

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

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

Refactoring DevOps with DevOps

How We Used DevOps

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

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

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

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

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

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

Relentless Improvement

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

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

About Adam Mattis

Adam Mattis is a SAFe Program Consultant Trainer (SPCT)

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

View all posts by Adam Mattis

Share:

Back to: All Blog Posts

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

Agility Fuel – Powering Agile Teams

Agility Fuel

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

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

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

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

Thinking in Feedback

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

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

Metric

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

Category

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

Stock

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

Type

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

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

Delay

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

Limits

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

A Few Examples

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

ART Velocity

Agility Fuel

Discussion:

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

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

Percent Unit Test Coverage

Agility Fuel

Discussion:

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

Top Exit Pages

Agility Fuel

Discussion:

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

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

Caution

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

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

Conclusion

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

About Allison Agile

Lee Allison is a SAFe 5.0 Program Consultant

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

View all posts by Allison Agile

Share:

Back to: All Blog Posts

Next: Tips to Pass Your SAFe Exam and Get Certified

Intel & business agility using data, Value Stream Optimization with DevOps, Systems Architects and the ART

Safe Business Agility Podcast Cover Image

Learn how Intel is achieving business agility by streamlining data, as well as implementing Agile and DevOps. Hear how optimizing value streams helped an organization and answer questions about incorporating DevOps into a SAFe transformation.

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

Share:

SAFe in the News

Scaling Agile, adopting AI: How Intel is making IT a strategic part of the business

By Stephanie Condon and published on ZDNet

Full article

SAFe in the Trenches

Hear Marc Rix share an experience from the field where you worked with an organization on Value stream optimization and how that impacted their DevOps initiative.

To learn more DevOps and Release on Demand – one of the Core Competencies of a Lean Enterprise, visit scaledagileframework.com

Audio CoP

The Audio Community of Practice section of the show is where we answer YOUR most frequently asked and submitted questions. If you have a question for us to answer on air, please send it to podcast@scaledagile.com

The two questions we answer in this episode are:

  • How do you adopt DevOps in SAFe? Do you form a separate team or incorporate into Agile teams?
  • What is a DevOps engineer?

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Cerno – SAFe Implementation for IT: A Case Study

“We collaborate more than ever with our customers by involving them in planning as much as we can. And we deliver frequent demos—even beyond customers’ expectations. Our customers have found communication to be more effective since the SAFe implementation.”

Sam Wu, Agile Head Coach and Training Director, Cerno

Challenge:

Deliver custom solutions faster and with higher quality for clients.

Industry:

Information Technology, Software

Results:

  • Delivery cycle time dropped by 58%
  • The rate of release failure went down from 0.6 times on average per release to 0
  • The interface automation level increased from zero to 70 percent
  • Reported defects decreased from 13 times per release to five

Best Practices:

  • Power through setbacks – Find solutions and don’t let them stop your momentum.
  • Assess regularly – Inspect & Adapt and DevOps health checks keep teams aware of progress and on track toward goals.
  • Choose a compatible partner – A partner with a business view, not just R&D, moved Cerno ahead with training and coaching.

Introduction

As a custom software factory, Cerno is poised for rapid growth as part of China’s expansive technology market. The company delivers technologies such as artificial intelligence, blockchain, cloud computing, open source software, and IoT solutions for a diverse range of clients, from logistics to government.

Cerno - SAFe Implementation for IT

To compete effectively, Cerno set out to elevate the speed of delivery, reduce defects, and improve the quality of its solutions in the long term, with the ultimate objective of being more client-focused.

“We needed a next-generation software development method to meet customer needs and reach our goals,” explained Sam Wu, Agile Head Coach and Training Director, Cerno.

Cerno’s founders brought experience in developing software for the financial industry. They found the ‘weak matrix’ structure worked in HR outsourcing, but not so well in product delivery. (A weak matrix is an organizational structure in which the balance of power tilts decisively in the direction of line or functional management.)

And while the traditionally waterfall company had experimented with Lean-Agile development in the past, they lacked the training or business support to build momentum.

SAFe®: The Path from Strategy to Delivery

While attending Leading SAFe® training, a Cerno executive saw a promising path to Agile, leading Cerno to adopt the Scaled Agile Framework® (SAFe). “It was clear that we needed SAFe to make Cerno a total Agile enterprise, to expand Agile not only to product lines but also to the business and functional departments such as HR and finance,” explained Liu Yilei, VP, Cerno. “We saw SAFe as the model that would take us from strategy to delivery.

“SAFe provided a comprehensive toolkit and an easy way to move forward,” added Wu, who was hired at that time to lead the effort as the internal change agent. At the same time, the company brought in SAFe Gold partner Aura International for coaching and training.

Per the SAFe Implementation Roadmap, James Li, Principal Consultant from Aura, led the SAFe Executive Workshop. Jack Xu, Senior Consultant from Aura, delivered SAFe® for Teams training and helped prepare for the first Program Increment (PI) planning event. They organized teams, reconfigured the office to better support those teams, and reorganized the product plan with user-story mapping.

For the first Agile Release Train launch, they began with four Agile teams—the entire R&D team plus Infrastructure and Operations—on an existing initiative to digitalize a logistics solution for a client.

From that first PI, team leaders embraced the Lean-Agile mindset. They identified priorities based on business value and began allowing people to self-organize. Instead of waiting to be assigned work, developers identified the work based on business objectives, committed to the work in PI Planning, and moved forward with it.

More Stories in Less Time—Despite Setbacks

Though Cerno set out to follow SAFe by the book, they ran into roadblocks that forced mid-course adjustments. In middle of the first PI, the Systems Architect left, leading Cerno to assemble a team to assume his responsibilities.

Additionally, the customer cut some funding because of market forces. And when managers wanted to move some teams to another client project, it nearly stopped the train. Given technical and capacity challenges, Cerno chose to postpone 15 percent of the high-risk PI objectives and scale back the size of the train.

Developers also found it challenging to transition from private to public code, a decision made to reduce bottlenecks in bug fixes and hidden technical debt. As the project team transitioned away from three-week waterfall development, the coaching team helped set code standards. In time, they found that developers took more pride in their code because of its public nature.

Even with the early challenges, the Inspect and Adapt session after the first PI showed the teams had met PI objectives and reduced defects. The ART could produce 45 stories per two-week iteration, on average, by the end of the first PI, compared to 30 stories per three-week iteration in waterfall.

Cerno - SAFe Implementation for IT

Routine DevOps Health Checks

When Cerno first introduced DevOps practices, the company lacked a SAFe DevOps Practitioner. Still, they made progress on a delivery pipeline and staging environment, supported a grayscale release of a product, and shortened the time to release future versions.

Additionally, they formed a new system integration testing (SIT) plan that shrunk testing time by 25 percent initially, and then by half, freeing the development team to put more effort into new features.

To expedite progress, they began conducting DevOps health checks. Early on, those checks uncovered opportunities to improve delivery. To stay on track, they now perform this exercise every PI. With the habit of regular checks, Cerno has made strides with automated testing and continuous integration/continuous deployment.

To support their efforts, they also established Communities of Practice and hold monthly technical workshops for developers.

Delivery Cycle Time Down 58 Percent

Today, Cerno runs two ARTs with 80 people. These high-confidence teams agree on, and begin working on, requirements faster. They communicate and collaborate more tightly than before they introduced SAFe and are continuously improving.

When the ART completed work with one client, they simply switched the train to support another logistics client with a similar solution—effectively a plug-and-play release train. The company then added a second ART to deliver value to another client. Each train continues to serve a single client.

To date, Cerno has made remarkable progress:

  • Delivery cycle time dropped from 3½ weeks to two weeks, or 58 percent
  • The average offline time for a new production environment release decreased from 3½ hours to half an hour
  • The rate of release failure went down from 0.6 times on average per release to 0
  • The interface automation level increased from zero to 70 percent
  • Reported defects decreased from 13 times per release to five

Most importantly, Cerno realized its goal of becoming a more customer-centric organization.

“We collaborate more than ever with our customers by involving them in planning as much as we can. And we deliver frequent demos—even beyond customers’ expectations,” Wu said. “Our customers have found communication to be more effective since the SAFe implementation.

“This is the first SAFe transformation case I have coached in a local company in China,” Li said. “Although there’s still more to improve, it is really a great and wonderful start! It is a significant milestone for SAFe in China.”

Looking ahead, Cerno is building toward agility beyond solution delivery, into administrative management and marketing—to become a total Agile enterprise.

Back to: All Case Studies

Suggested Case Study: Amdocs

Easterseals Northern California – SAFe for Healthcare

Easterseals Northern California -  SAFe for Healthcare

“We began seeing value within weeks or months of launching the first release train. Leaders and business owners could very quickly see we were working on the things that were important to them.”

Jeff Hallett, VP, Product Management

Challenge:

Tighten alignment between the business and IT in order to bring mission-supporting applications to users sooner.

Industry:

Healthcare, Non-Profit

Results:

  • Higher quality on a more predictable and reliable timeline
  • Lower defect levels
  • The highest employee engagement score in the company in the IT group

Best Practices:

  • Use a ‘velvet glove’ approach – Easterseals got leaders and business owners accustomed to the mindset and practices before introducing it as SAFe, which provided low-friction engagement for business stakeholders
  • Tie efforts to principles – They connected everything back to principles and shared values
  • Staff smartly – They put change leaders in key positions
  • Keep an eye on progress – Retrospectives with metrics demonstrated results

Introduction

Nonprofits are better known for their compassion than their innovation. But Easterseals Northern California is proving that being Agile contributes directly to its mission—to responsibly disrupt and transform home- and center-based health care.

For 90 years, the Bay Area nonprofit has been helping people with autism and other developmental disabilities address life’s challenges, achieve personal goals, and gain greater independence for everyday living.

SAFe for Healthcare

In doing so, Easterseals Northern California administers an impressive level of care:

  • 7,500 clients in an average month
  • 96,000 clinical appointments per week
  • 25,000 claims per week
  • 1 million managed treatments a year
  • 10,000 active health practitioners

To manage that volume, Easterseals depends on front- and back-office applications for clinical operations, case management, billing, and more. And it must do it all in a HIPAA-compliant security and privacy environment.

For the IT team, staying ahead of business needs has often proven daunting. In the past, staff and contracted team members across the U.S., Ukraine, and Vietnam used “scrum-like” practices, however, the different geographic groups didn’t work together or identify dependencies with other teams. And in the absence of stated priorities, teams were always tackling the most urgent ad hoc requests.

“It was a tyranny of the urgent,” explained Jeff Hallett, VP, Product Management. “Ad hoc requests were taken with no oversight or triage. We knew we needed better alignment.”

The Right Time for Real Transformation

For technology leaders, the vision was clear…

  • Tighter alignment between business owners and teams
  • Fewer surprises and reactive work requests
  • Less work-in-progress
  • More transparency
  • Consistency in portfolio intake, prioritization, and backlogs
  • And better accounting for capacity and business value

But the path to reach those objectives was littered with obstacles. Over the years, IT had pushed to adopt Lean-Agile practices, which included experimenting with the Scaled Agile Framework® (SAFe®). However, early efforts at applying the Framework fell short—likely due to a variety of reasons, such as lack of business support and training.

But in 2018, the timing seemed right to try again. At that time, the nonprofit was beginning the transition from paper-based processes to electronic management systems. Concurrently, leadership was pushing for decentralized decision-making and network-based management. IT leaders believed in SAFe, but this time, they would take a different approach to rollout.

“Technology leadership liked the scalability and the business engagement of SAFe, and believed that it would make a difference,” said Hallett, who joined Easterseals at that time to help drive the transformation as a SAFe® Program Consultant (SPC).

First, Cultivating Mindset

SAFe for Healthcare

For a renewed effort at transformation, Easterseals would introduce some of the practices of SAFe to members of the business, but leave out some of the SAFe-specific terminology early on. Transformation leaders emphasized mindset—using the Agile Manifesto—to get the business on board and begin changing the culture.

Instead of training leadership immediately, the organization first began involving them in activities such as portfolio management, prioritization, and epic grooming.
Only later did they double back to train leadership and begin using terminology and practices with them. That was key to their phased, incremental approach to preparing for and holding the first Program Increment (PI).

Training started with the technology group and moved on to business roles. A few business members took SAFe® for Teams and SAFe® Product Owner/Product Manager to build understanding and excitement. When they offered SAFe® for Teams, they explained that this was the exact process they had already been following.

A Phased, Incremental Rollout

Easterseals took a phased approach to the SAFe transformation, like building layers of a cake. It all rested on a foundation of Lean-Agile leadership. To that end, they filled key positions with “change leaders,” which included dedicated Portfolio managers and Scrum masters.

They layered the rest on top of that firm foundation: Lean-Agile principles; teams and Agile Release Trains (ARTs) that embrace the core concepts of SAFe; cadence and synchronization; DevOps and releasability; an architectural runway; PI planning; system demos; inspect and adapt practices; and IP iterations.

To pave a path for success, they began with the Portfolio SAFe configuration to secure commitment from internal business partners, standardize requests, gather needs from the business, and analyze for value.
About 75 people joined the first Program Increment (PI) planning event, from technology, clinical programs, business excellence, and the PMO.

At that first event, some grumbled about having to spend two days away from their regular work. However, by the second PI, they were so engaged that some people said two days wasn’t enough time. From the start, progress was clear.
“I noticed an immediate benefit,” recalled Trista Travis, IT Program Manager and the nonprofit’s Release Train Engineer (RTE). “Because the second someone put a Post-It note that had a dependency up on our Program Board, they realized, ‘Oh, we really do need to collaborate across teams.’”

As teams became accustomed to the new way of working, some learned the hard way. After one team committed to 150 story points, they soon found themselves in over their heads.
“We let them get to the point where white flags were raised,” Travis said. “Then we had a session where we took a step back, erased the white board, and started figuring it out from scratch. It was a lot of making the hard choices and throwing stuff over the side of the boat.”

Today: Excitement and Buy-in from Top to Bottom

In less than a year, Easterseals Northern California has successfully changed the organization’s mindset and way of working, and started seeing the fruits of their efforts.

“We began seeing value within weeks or months of launching the first release train,” Hallett said. “Leaders and business owners could very quickly see we were working on the things that were important to them.”

They now run two Agile Release Trains and five Value Streams. They are committed to holding ceremonies on cadence. Sprint goals are aligned with PI objectives. Teams are collaborating. They regularly use metrics and retrospectives to assess progress.

As Easterseals expanded its SAFe practices, leaders found that they lacked the tooling they needed as current configurations didn’t match the new ways of working. Thus, as they established a regular cadence and ceremonies, they implemented new tooling that worked in step with their practices.

Most importantly, they’re seeing excitement and buy-in across most teams and leadership. In fact, leaders have started asking to participate more after hearing positive feedback from teams.

In less than a year, they have achieved strong cross-team and cross-Value Stream collaboration, alignment, and management of dependencies—reducing unexpected requests for the IT team.

Easterseals Northern California -  SAFe for Healthcare

Business partners are involved in planning and conversations from the beginning, ensuring solutions are more on the mark—upping the satisfaction in delivered solutions and increasing value delivered:

  • Easterseals hit 83 percent for achieved objectives in its first PI
  • 70 percent or more of the delivered story points in releases are directly traceable to items on the Portfolio strategic roadmap agreed on with the business
  • IT delivers also higher quality on a more predictable and reliable timeline
  • Defect levels are down
  • IT has the highest employee engagement score in the company

Ultimately, getting quality applications sooner enables staff and clinical practitioners to focus more on transforming home- and center-based health care.

“Now, there’s a direct line-of-sight between work in progress and how it helps with the Easterseals mission,” Hallett said.

Training At-a-Glance

Watch the Easterseals presentation from the Global SAFe Summit – October, 2019

Back to: All Case Studies

Suggested Case Study:

Center for Medicare and Medicaid Services

Bosch / ETAS – Agile Framework

Presented at 2019 Global SAFe Summit, San Diego Oct. 2, 2019

Share:

For over 130 years the name “Bosch” has been associated with forward-looking technology and trailblazing inventions that have made history. Bosch does business all over the world and is active in the most wide-ranging sectors. In particular, BOSCH is the largest supplier for the global automotive industry.

Dr. Volkmar Denner, CEO of Bosch; “For Bosch agility is crucial, it allows us to adjust to the increasing speed of change around us. Agility allows us to remain in a position as an innovation leader.”

This video tells the story of how an enterprise of more than 70,000 knowledge workers and traditionally independent business areas have faced the challenge of an agile transformation and started an alignment to common a strategy for mobility solutions and the SAFe journey. It provides a deep dive into one of Bosch`s Business Units, ETAS, and shows what was already achieved by introducing SAFe and focusing on current activities in Lean Portfolio Management and how the company organizational structure is being adopted as a consequence of the SAFe transformation.

Back to: Customer Stories

Next: PepsiCo Customer Story

Anthem – Agile Transformation Journey

Anthem Agile Transformation Journey

Share:

Anthem used an integrated SAFe approach across Agile and DevOps (including Quality Assurance capability) to drive tangible benefits in the form of improvements in quality, time to market and predictability, and increased collaboration between IT and business.

They chose to apply the Scaled Agile Framework incrementally, rather than a big bang rollout. Approaching the problem from both top-down and bottoms-up, the transformation for the enterprise concentrated on one vertical slice at a time working with both Business and IT leaders in an area to enable Lean Agile practices and provide hands-on coaching and education to drive the adoption of the Agile mindset.

They worked closely with their partners to go beyond just the mechanics of training and coaching with a focus on sustaining the change and moving towards true enterprise business agility.

Back to: Customer Stories

Next: Easterseals Customer Story

Murex – SAFe Implementation for Financial Software

Murex - SAFe Implementation for Financial Software

“Using SAFe to deploy agility at scale across our product factory has been fundamental to putting in place the mindset necessary for our transition to DevOps across our value chain. We still have further to go on this journey, but the benefits we see have proven that the SAFe framework was the right choice to accelerate our transformation.”

Jonathan Coyle, Head of Agile Factory Operations

Challenge:

With its MX.3 platform in use across the globe, Murex sought to maintain and build upon its market-leading position while continuing to respond rapidly to support the changing needs of clients and global regulatory demands.

Industry:

Information Technology, Financial Services

Solution:

SAFe®

Results:

  • 10X faster production-like testing
  • A full functional testing cycle in just one hour
  • 85% reduction in user story cycle time
  • Time to release for internal test management system dropped from 37 man-days to two
  • 95 percent of those asked would not want to return to the old way of working

Best Practices:

  • Communicate continuously – You cannot over-communicate on your vision or the ‘why.’ Constantly reinforce the mission context.
  • Prepare for challenges – Be ready to tackle the problems that emerge quickly as teams and trains accelerate.
  • Anticipate changes in culture and people – Don’t underestimate the cultural impacts that agility at scale brings and be ready to invest in people.
  • Invest in collaboration infrastructure – Murex invested heavily in digital solutions to help foster collaboration between distributed teams.
  • Provide coaching and SAFe training – Coaching and training guides teams and individuals through the huge changes that they go through during the transformation and sets the stage for success.

Introduction

Every day, over 50,000 people in 60 countries rely on financial software from Murex. For more than 30 years, Murex has provided financial technology solutions for capital markets, from banking and asset management to energy and commodities. The independent, Paris-based company employs more than 2,200 people across 17 countries.

Murex’s flagship, award-winning platform, MX.3, supports trading, treasury, risk, and post-trade operations, enabling clients to better meet regulatory requirements, manage risk, and control IT costs. To maintain its industry-leading position, Murex continues focusing on building transformative technology, but faces numerous challenges in those efforts:

Murex - SAFe Implementation for Financial Software
  • Changing regulations across regions
  • Complex and growing customer demands
  • Legacy IT and processes

As well, Murex wanted to improve its quality and time-to-market in getting new capabilities to customers.

“The impact of technology and regulation on financial institutions means they need to find new ways to adapt faster,” explained Joe Iafigliola, Head of Americas for Murex. “To answer this challenge, Murex realized that we needed to provide a more flexible and Agile approach to project delivery. While this brings more predictability and convergence, it also allows greater flexibility to make changes that are required during a project.”

Pursuing Continuous Delivery the SAFe® Way

Murex - SAFe Implementation for Financial Software

Murex chose to apply SAFe to both its product development and the infrastructure supporting product development for proper business agility, and thus created a Value Stream for each:

Value Stream #1 – Development of MX.3, its flagship product

Murex’s first Value Stream onboarded 700 engineers in eight ARTs for the development of its MX.3 trading, risk, and post-trade platform. This ART targets consistent Agile development practices, continuous integration, improved cycle time, and a faster feedback loop.

Value Stream #2 – Infrastructure evolution for MX.3 development and delivery

Murex created a second Value Stream to evolve the underlying development infrastructure, which includes development environments, versioning, build pipeline, and test management systems. Before SAFe, this portfolio released about every 10 weeks. Following the SAFe implementation, this timeframe has been reduced to two weeks.

Both Value Streams run with a DevOps flow. They follow sprint-based development on a two-week cadence with a continuous delivery pipeline. And batch sizes, iterations, and feedback cycles—all hallmarks of DevOps best practices—are all reduced.

Murex has also started piloting a DevOps approach for client rollouts and upgrades. They created a full development environment for customization of the MX.3 platform for clients. They now handle configuration, tests, test data, and infrastructure as code, and every piece is importable and exportable, and version-able in source control. Smaller changes flow to production more easily, reducing the challenges associated with large releases.

In pilot tests, the SAFe DevOps approach has shown promising results and is fostering more collaborative relations with clients.

“We found that, with a DevOps approach, validation timescales can be cut in half when compared to traditional methods,” added Hassan Kamal, Head of Software Engineering. “This unlocks huge potential in terms of delivering incremental value because we can react faster to changing market and regulatory requirements.”

Impressive Productivity Gains

As of today, Murex has trained more than 1,000 people in SAFe, or half the company, with teams distributed across its three development centers in Paris, Dublin, and Beirut. Its efforts have driven measurable progress across numerous benchmarks:

  • 10X faster production-like testing – Client Delivery teams can now simulate 10 weeks of real production activity in a single weekend
  • Complete testing in just one hour, instead of days – The full client delivery testing cycle, including environment provisioning, functional tests, and upstream/downstream interface validation dropped from five days to just one hour, making it possible to run this full suite to customize each new customer configuration
  • 85% reduction in user story cycle time – Internal user story cycle for MX.3 platform development time dropped from 90 days to 15 days
  • Lower release cost for internal IS – The time to release for the internal test management system dropped from 37 man-days to two
  • Positive feedback from employees – 95 percent of those asked would not want to return to the old way of working (pre-SAFe)

Just as critical as the numbers, Murex’s people have embraced the mindset required to make the transformation.

“The most notable difference at Murex is a change in the way we plan and execute solution development. We do not commit to tasks—we commit to outcomes—and we let the teams decide how best to get there,” said Wissam Ghamroun, Head of EMEA Customer Delivery Services.

The company credits SAFe with helping it adopt best-practice engineering standards around test-driven development and CICD.

“Using SAFe to deploy agility at scale across our product factory has been fundamental to putting in place the mindset necessary for the transition to DevOps across our value chain,” Coyle said. “We still have further to go on this journey, but the benefits we see have proven that the SAFe framework was the right choice to accelerate our transformation.”

Back to: All Case Studies

Suggested Case Study: Westpac

Easterseals – A Unique SAFe Journey in Healthcare IT

Presented at 2019 Global SAFe Summit, San Diego Oct. 2, 2019

Share:

Easterseals Bay Area, as a non-profit provider of behavioral health therapy, provided a unique challenge and environment for the adoption of SAFe for its IT department. In order to overcome some of the unique challenges of our environment, we embarked on a year-long incremental approach rather than a traditional implementation, adopting techniques and practices as they supported our growth and learning in scaled agility. Additionally, due to the large number of conflicting and dynamic inputs to the teams, we started our SAFe journey at the Portfolio level to get our flow and capacity under control while we developed the knowledge and maturity of our agile teams underneath. At Easterseals we will share with you how we took this innovative trail by focusing on mindset and principles that would enable the business and teams to partner with us without the initial intimidation of a radically new framework and terminology.

Back to: Customer Stories

Next: Standard Bank Customer Story