Northwestern Mutual Case Study: A SAFe Implementation Retrospection

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

 

This article discusses Northwestern Mutual’s SAFe adoption from the perspective of the consulting company which actually led the adoption. This was written because the SAFe Case Study for Northwestern was written without consulting the person who actually led the adoption, Al Shalloway. Al used several concepts that were not in SAFe at the time (some still aren’t) and the SAFe writeup does not discuss this, even though they were critical for the success achieved.

It starts with how the implementation was done, discusses 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 several years, there are still several key practices and perspectives that are 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.”

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. Net Objectives won the bid in a two way competition mostly on the basis of their experience with Lean-Agile and our understanding of SAFe.

They had been doing something like SAFe for years – having started using Lean methods in 2005 on the basis of their deep experience with systems-thinking. Al Shalloway had met with Dean Leffingwell in 2011 about joining forces since, at the time, he and Net Objectives had more successful large scale Agile transformations than anyone else. Al 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
  • Its 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’).

Al wasn’t particularly worried about its supposed heaviness since he’d be running the transformation. He 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 Net Objectives varied from the SAFe standard start and opportunities we didn’t take

There were several things that Al saw that were either missing in SAFe or were not done in the more effective Net Objectives manner. He wasn’t particularly concerned about using SAFe instead of the standard Net Objectives approach he considered our more optimal approach to be because he felt getting Northwestern aligned with SAFe seemed to be a good starting point.

These are what Net Objectives did differently:

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

The following were things Net Objectives normally did but did not do in this case.

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. We 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, we weren’t waiting for Northwestern to be ready. Few executives/directors feel ready. At one point they asked Al if they were ready and he 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, Al didn’t like it. His 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. Al had wanted to use Net Objectives 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 on what they wanted was exactly what Al had thought they would want  “following” it he essentially just presented the deck IHe 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 some place safely and comfortably. They don’t care how the engine works.

Kanban at the shared services level

Shared services are 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.

Al 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 different beasts 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

50 of the 125 people who were going to be in the first planning event required Scrum training. At the time SAFe’s Scrum training materials were not of the quality they are now (good job SAI improving things here). But Al 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 his 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 Al had 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, Al 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: We do not recommend this as a way to do Scrum training, but it illustrated the point that people learn best in the right environment. We 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). 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, Al decided not to press the issue here. Prior to Net Objectives’ 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 we 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, Al’s 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. Al believes 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 Al 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 Al would have done differently now.

Spend more energy on using MBIs

These are the most important concepts and practices 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, At the time Al didn’t totally appreciate its power. It was created by Guy Beaver, one of Net Objectives senior consultants. In a nutshell, the basic agreements are:

  • Work on items that will realize the greatest amount of Business value across the enterprise.
  • Collaborate with 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 Al believed 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. The 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, he’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. At one point we were gold partners.  Eventually, however, we felt that SAFe was getting too complex due to how it is architected by levels and we’ve ended our relationship with SAI.

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 Al’s SPC classes.

Where to get more information

Net Objectives has since been acquired by the PMI. They are currently creating the Disciplined Agile Value Stream Consultant workshop as well as the DA FLEX Playbook for SAFe workshop.

We have also created a 45 minute presentation of the DA FLEX Playbook for SAFe. This is still a work in process but provides great insights on how to improve a SAFe adoption.

This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.