Northwestern Mutual Case Study: A SAFe Implementation Retrospection

Related pages

Online lLearning

Related resources

Provide Feedback

This article discusses Northwestern Mutual’s SAFe adoption from the perspective of the lead consulting company leading the adoption. It starts with how the implementation was done and, in particular, cover those things that were done that were not in SAFe at the time but were common practice for Net Objectives. It will discuss what worked, what could have been better, and what we would have done differently if we were to do it again. It closes with what we can learn from this engagement and provide some resources for further reading.

The bottom line is that even though SAFe has improved over the last six years, there are still several key things that are either not addressed or could be improved. The bottom line is that SAFe is a framework for project management at scale. It may be a good start, but it should not be the targeted end state. As a framework, follow Bruce Lee’s advice, “Absorb what is useful, discard what is useless, and add what is specifically your own.”

For more information about this implementation see the Northwestern case study by SAI

SAFe at Northwestern Mutual

In 2012, Northwestern Mutual was looking for a company with SAFe experience to guide them in their Lean-Agile transformation via SAFe. We basically won the bid in a two way competition mostly on the basis of our experience with Lean-Agile and our understanding of SAFe.

We had been doing something like SAFe for years – having started using Lean methods in 2005 on the basis of our deep experience with systems-thinking. I had met with Dean Leffingwell in 2011 about joining forces since, at the time, he and our company had had more successful large scale Agile transformations than anyone else I knew. I liked SAFe for several reasons, but the most were:

  • It addressed business, management and teams
  • It attended to the ecosystem people found themselves in
  • It had a real role for management
  • It’s planning event was a great way to create collaboration and make all (most anyway) dependencies visible.
  • It had the product management – product owner relationship that we’d found essential when you had multiple stakeholders talking to multiple teams (even though otherwise their product management was weak, it was no worse than others’).

I wasn’t particularly worried about its supposed heaviness since we’d be running the transformation. I brought in Jennifer Fawcett from SAI to provide deeper experience with SAFe itself (in particular, the planning event).

A little background

The “train” we were working with was comprised of about 6 teams totaling 125 people. There were organized functionally, with the largest “team” being about 50 people. There was a shared services group of about 250 people, about half of whom interacted with this train.

How we varied from the SAFe standard start and opportunities we didn’t take

There were several things that I saw were either missing in SAFe or were not done in the way we did. I wasn’t particularly concerned about using SAFe instead of what I considered our more optimal approach to be because I felt getting Northwestern aligned with SAFe seemed to be a good starting point.

These are what we did differently:

  • Didn’t do a quick all-in-all-the-way implementation
  • Talked to Executives About Agile at Scale from the Top-Down
  • Kanban at the shared services level
  • Improved the ecosystem with small changes.
  • Scrum training

Here are things we normally do but did not do in this case.

  • Agile Product Management using Minimum Business Increments (MBIs)
  • Acceptance Test-Driven-Development

What we added or did differently

Didn’t do a quick all-in, all-the-way implementation

We were under a lot of pressure from SAI to do the quick all-in, all-the-way adoption of SAFe that was fairly universal at the time. I wouldn’t budge from our stance that we needed to get management buy-in first and that that would take some time. It also enabled us to build up the backlogs for a better extent.

To be clear, I wasn’t waiting for Northwestern to be ready. Few executives/directors feel ready. At one point they asked me if they were ready and I responded, “the question isn’t are you totally ready, it’s whether starting now will be an improvement – and yes, I think it will be.” We moved forward at that point. Taking the slower start was definitely the right move and is more common now.

Lesson Learned: Although you’d like to do an implementation as fast as possible, too fast can result in backlash.

Talking to executives about agile at scale from the top-down

At the time SAI had a deck for a 60 minute introduction to SAFe for executives. It started with getting Agile at the team level then coordinating the teams and finally the role business stakeholders had in the implementation. To be candid, I didn’t like it. My experience with executives and product management was (and still is) that they don’t care about Agile teams. They are interested in realizing value for their customers and the business quickly, predictably and sustainably, which is our definition of business agility.

We had two executive presentations scheduled. I had wanted to use our materials to explain driving SAFe from business value, but bowed to SAI’s decision to go with their standard presentation. The first presentation didn’t go well. We accepted their feedback that the executives wanted to know the why of SAFe from a business perspective not from a team-up perspective. Their feedback was exactly what I had thought would happen and in “following” it I essentially just presented the deck I had wanted to use in the first place. They loved it.

Lesson Learned: Talk to executives and directors from their perspective. It’s like selling a car, they care about getting someplace safely and comfortably. They don’t care how the engine works.

Kanban at the shared services level

By shared services I mean groups that work across the organization supporting teams working on different portfolios. These are typically business intelligence, data analysts, ops and the like. In 2012, SAFe did not have Kanban at the shared services. Fortunately, Northwestern’s shared services group was well advanced for the time. They had already been looking at load balancing their work and just needed a little nudge to go to a true Kanban system. We did two things that helped:

  • Created a backlog for their shared services teams so people making requests of them could see the delays they’d incur
  • Requested prioritization from the business stakeholders when there was a request conflict. When stakeholders give that, shared services managers would make the decision on what to do based on either what was clear for greater value realization or, when that was not clear, based on managing work-in-process.

I felt that they were a key to their overall success. Here is a tip when doing a planning event that affects shared service: Have them sit in the middle of the room. That way they can both be looking for places they’ll be needed, people will have ready access to them, and since people will be going from one team to another, walking through or near the shared services team may jog them into realizing shared services will be needed by them.

Lesson Learned: Shared services and ops are a different beast than development or maintenance teams. They get last minute requests from multiple sources. Managing them in anything other than a flow (Kanban) model is virtually always sub-optimal.

Improving the ecosystem with small changes

The “train” to be undergoing SAFe was already reasonably cross-functional with the exception of shared services. But there were many small-adjustments that could improve things. In 2012 we already had a fair number of techniques to improve cross-functionality. The idea of feature teams or component teams was already well known. But feature teams are often difficult to achieve and we already had many techniques to improve team structure even when feature teams were not available. Some of the technique we used besides this were:

  • When a team either supports another team with primarily one or two members or with a reasonable amount of their capacity spread across several team member, assign the supported team full-time members of the supporting team for the life of the project they were working on. Note, this did not change who people reported to, but did often require these ‘shared’ people to attend to more than one daily standup.
  • When one person was required to support two teams, have them embed themselves in the teams they supported.
  • When one person was required to support more than two teams have them use a Kanban board for the requests of them

While this didn’t significantly change the structure, the small adjustments made paid huge dividends. It also illustrated the thought process of future improvements that could be made.

Lesson Learned: Small adjustments to move toward greater cross-functionality can make a big difference.

Scrum training

We had to train 50 of the 125 people who were going to be in the first planning event. At the time SAFe’s Scrum training materials were not of the quality they are now (good job SAI improving things here). But I felt that it was more important to use their materials instead of our own since the SAI materials provided Scrum as it was integrated with SAFe. This was based on my experience with systems-thinking. SAFe promotes that to do Agile at scale you needed good Agile teams. This implies that you should start with the teams. But I had already learned that if you have a good environment within which teams can work you can do Scrum training both better and more easily. People will pick it up because they understand the need for sprints and staying in synch.

It’s also worth pointing out an interesting event. At the last-minute Northwestern decided to add a small, mostly independent team, with no Agile experience to the train. They had missed the Scrum training and were totally unprepared. Because we had several SPCs available, I assigned one to this team to teach them Scrum during the planning events. As requests were made of the teams our SPC explained why. They learned Scrum fairly well.

Note: I do not recommend this as a way to do Scrum training, but it illustrated the point that people learn best in the right environment. I do recommend providing people an understanding of the bigger picture before doing Scrum (or Kanban) training.

Lesson Learned: People will learn Scrum more easily within the context of a framework that supports it. Also, always have a few extra people helping out in case they are needed.

What we didn’t do

Agile Product Management using Minimum Business Increments (MBIs)

Our greatest successes have been when we used Minimum Business Increments (MBIs). MBIs. This has several advantages:

  • It focuses everyone on what we should striving for customer realization
  • It provides upfront de-scoping so features defined under the MBIs are as small as they can be in order to be released
  • They force the development group to look at non-development issues that are required for business realization
  • They create visibility on the cycle time of the MBI
  • It provides a way of deciding what people who are constraints due to special skills should be working on

Unfortunately, I decided not to press the issue here. Prior to our involvement Northwestern had been a Scrum shop and their Scrum provider used Scrum’s product ownership approach. While not really effective, it was a battle I decided not to fight.

Lesson Learned: Strive harder to the right thing in the face of resistance.

Acceptance Test-Driven Development

Although Acceptance Test-Driven Development (ATDD) is one of the most powerful methods to use, it is not always the place to start. If you don’t start with it, you should definitely adopt it as soon as possible. The issue here was that we were making enough changes and there wasn’t budget for this in a separate pass.

Lesson Learned: We have since learned how to provide ATDD training to ARTs in a much more cost-effective way than in 2012.

What worked and what could have worked better

Basically it worked, hence SAI’s case study. With the exception of the product management part, I’m not sure we could have done significantly better at the start. One of the indications that success was coming was during the planning event when the directors would come in and watch and see what was going on. Although they didn’t really understand the details, they saw the collaboration, excitement and progress being made. I believe the biggest impacts SAFe had on the organization were:

  • Creating visibility of the dependencies upon the team
  • Providing a common cadence for everyone to work within
  • The perspective that it was more important to achieve business value than it was to focus on the teams
  • Getting directors involved, even if it were to a small extent

What I would do differently

We’ve learned a lot in the last six years. Both new methods and the importance of some older ones. This is what I would have done differently now.

Spend more energy on using MBIs

These are the number one thing we use now when working at scale.

Use our Guardrails system to increase collaboration and alignment. Although we had our guardrails system for people to work together at the time of the SAFe implementation, I’ll be candid in that I didn’t totally appreciate its power. It was created by Guy Beaver, one of our senior consultants. In a nutshell, the basic agreements are:

  • Work on items that will realize the greatest amount of Business valueacross the enterprise.
  • Collaboratewith each other in order to maximize the realization of Business value across the enterprise.
  • Ensure that all work will be made
  • Take the necessary steps to sustain or increase predictability.
  • Keep the work throughout the value stream within capacity.
  • Encourage everyone to strive for continuous improvement.

In the last few years I’ve seen how they are essential and avoid the challenge of people following an approach instead of making agreements with each other. Now I’ll not do a transformation / implementation without them. It turns out they are very easy to use and have not had a client not want to adopt them. These are not only very effective, but they set the stage for thinking instead of just following an approach.

Moving away from three-month planning events to a flow model

While I believe SAFe was a great place to start for Northwestern, there was no real need to be working with the large batches of planning after the first event. I figure a three month planning event with the number of people involved. Represents about 560 person months. While starting with the planning event was invaluable, nowadays, unless truly large trains (as opposed to collections of relatively small teams) are present, I’d recommend one planning event and then going to continuous refined of backlogs to create a pull system. We’ve done this with groups up to about 300 people comprised into 30 or so teams. After the event, they just continue to refine their backlogs and use a flow or iterative model.

What we can learn from this experience

SAFe is often a good place to start. But with a few additions, one can create a much better way to start. The use of MBIs from the very beginning, as well as better visibility on what’s tied to them provides greater alignment. Especially when combined with our guardrails system. These two changes alone can transform SAFe from a large batch planning project management system in to a true Agile at scale system. Continuous improvement is what it’s all about. The power of small batches is illustrated in Eli Goldratt’s (creator of Theory of Constraints) comment “sometimes reducing batch size is all it takes to bring a system out of chaos.”

A brief history of Net Objectives and SAFe

Al Shalloway, author of this document and CEO of Net Objectives, was the first person outside of SAI to teach or co-teach a SAFe course. But our involvement with SAFe goes back in many ways before SAFe because we’d been doing Lean for many years prior to SAFe’s inception. We were also contributors to SAFe, particularly in the area ATDD, technical practices, architecture and the use of Kanban at the shared services level. We started out as Bronze partners and we can still teach Implementing SAFe.

Here’s also what Chet Hendrickson (Agile and XP Guru) had to say about our SAFe practices, “I don’t do SAFe training. The only person in that space I trust is Al Shalloway at Net Objectives.” This comment was made after he had attended one of my SPC classes. I am sure if he knew our other SPCs he’d trust them as well (from whom do you think I’ve learned what I know?).

Where to get more information

Of course, if you’re interested in outside help for Lean-Agile and/or SAFe at scale, please drop me a line (

Another case study is of interest is the BMC -the SAFe case study. SAFe wasn’t actually done there but rather Israel Gat led an Agile transformation that was the foundation for much of Agile at Scale learning by many people. Although we were not involved with that Israel is both a long time associate and former employee of Net Objectives. His methods and our have long been consistent with each other.

FLEX (FLow for Enterprises Transformation) is a sub-site that discusses our approach.

FLEX and SAFe® describes our approach to SAFe.

The FLEX Resources is a good place to learn more about useful Lean-Agile concepts and the Agile Product Management approach.