SAFe (Scaled Agile Framework) Goes Mainstream

 If you have been here before, you know I’m a huge fan of Dean Leffingwell and his work on Agile. It seems that the mainstream business community is finally catching up. This is a great article by Jason Bloomberg for Forbes.

Scaling Agile Software Development for Digital Transformation

9/08/2014 @ 2:18PM |
Jason Bloomberg

True digital transformation initiatives require change at multiple levels of the organization. Revamping the customer experience with digital technologies is never a superficial change, as it requires better, more flexible software as well as a dynamic, agile organization to drive innovation and to respond to marketplace changes.

Agile software methodologies like Scrum and Extreme Programming (XP) are now established approaches for building software in dynamic environments. Agile approaches don’t solve every software problem, however, as they typically work best with relatively small, self-organizing teams.

Scaling Agile to the enterprise level is a challenge that The Scaled Agile Framework® (also known as SAFe™) means to address, as it combines Agile approaches with more enterprise-centric organizational practices. Yet, while SAFe has led to several dramatic successes, challenges still remain, especially as enterprises undergo the broader organizational change necessary for digital transformation success.

Success with SAFe™

SAFe is an interactive knowledge base for implementing Agile practices at enterprise scale, according to its Web site. This enterprise-driven approach is largely the brainchild of Dean Leffingwell, Director and Chief Methodologist at Scaled Agile, Inc. Leffingwell has been a leader in the software development industry for decades, having founded Requisite, Inc., the makers of the RequisitePro requirements management tool, now part of IBMs Rational division.

According to Leffingwell, Agile methodologies alone do not address top-down questions of business strategy, as Agile teams work bottom-up. “You can’t add up opinions of people to come up with the business strategy,” explains Leffingwell. “Some things require centralized decision making.”

SAFE, therefore, provides the organizational structure for top-down, centralized decision making that works in conjunction with self-organizing Agile teams. “SAFe promotes the core values of empowerment and decentralization of control, but not the decentralization of everything,” says Leffingwell. “Cascading centralization and decentralization leaves empowerment to the troops.”
In fact, neither top-down nor bottom-up adequately describe SAFe, according to Leffingwell. “Program execution happens at the program and team levels,” he explains. “The traditional models of centralized program planning and micro-technical-management are a thing of the past with SAFe. That is empowering.”

1931 John Deere - The High Tech of its Day
1931 John Deere – The High Tech of its Day

This balance of top-down control and bottom-up empowerment has shown notable success at several enterprises. “We’ve seen extraordinary work,” Leffingwell says. “30-50% improvement in productivity and quality, as well as a 2X – 3X improvement in time to market.” Furthermore, many SAFe success stories had little or no Agile to begin with. “BMC Software, John Deere & CoDiscount Tire – none had real Agile at the start, or maybe just a few Scrum teams.”

John Deere, in fact, is one of SAFe’s most notable success stories. “We knew we needed to increase our speed to market while keeping our budget and resources static,” said Steve Harty, former Agile Release Train Manager at John Deere. “Moving our team to Scrum was scary, challenging, and liberating, all at the same time.  Scrum was ‘our little secret’ that helped move our delivery time timeframe from 12-18 months to 2-4 weeks. Plus, our engineering teams were happier and customer satisfaction went up.”


Bob Hubbard
Lean Six Sigma Black Belt
AT&T Technical Development

Lean Marches Forward with SAFe

SAFe refers to the Scaled Agile Framework. According to the Scaled Agile Framework website (

The Scaled Agile Framework is a proven knowledge base for implementing agile practices at enterprise scale. Its primary user interface is a “Big Picture” graphic which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level.

The Big Picture describes three levels of scale:
Team, Program and Portfolio. Each of these scales the essential agile elements of Value (requirements and backlogs) Teams (from development team through portfolio) and Timebox (iteration, PSI, budget cycle). This model of agile adoption has been elaborated primarily in Dean Leffingwell’s books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and his scalingsoftwareagility blog.

Image-Detail of the Scaled Agile Framework (SAFe) Big Picture.
Detail of the Scaled Agile Framework (SAFe) Big Picture.


Further Reading

Leffingwell, Dean (2011).
Agile Software Requirements, Lean Requirements Practices for Teams, Programs, and the Enterprise,
Addison-Wesley Professional, ISBN 

Leffingwell, Dean (2007).
Scaling Software Agility, Best Practices for Large Enterprises,
Addison-Wesley Professional, ISBN 978-0321458193.

Top 10 Reasons for Kanban

While this short video has nothing to do with software development, it is a great overview of the benefits of implementing a kanban system.

Opining On Kanban

I became a kanban advocate after implementing a kanban system for our instructional design team during my time at Delta. Before implementing the kanban, leaders assigned work to team members. As is the case in most organizations, we rewarded our top performers by giving them more work. With the kanban in place, the entire team was responsible for moving work through the process. Not surprisingly, our top performers still did more work, but since the work process was now transparent, all the instructional designers improved their performance.

As I work to discover how kanbans can work in the software development process, I found the follow blog posts helpful. I hope you enjoy them and I encourage you to visit both sites for more info on how lean works in software development.

Bob Hubbard April 2011

This post is from Dan Ackerson & Matthias Marschall’s “Agile Web Development & Operations website @:

Scrum vs. Kanban

by Matthias Marschall on August 10, 2010 · 9 comments

When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which one is better suited for my own situation?

Scrum – A Fundamental Shift

Scrum is a well defined process framework for structuring your organization. Introducing Scrum is quite a change for a team not used to agile methodologies: They have to start working in iterations, build cross-functional teams, appoint a product owner and a scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits are well understood: Less superfluous specifications and less hand overs due to cross-functional teams, more flexibility in roadmap planning due to short sprints, etc. Switching your organization to use Scrum is a fundamental shift which will shake-up old habbits and transform them into more effective ones.

Scrum Leverages Commitment As Change Agent

The initial introduction of Scrum is not an end in itself of course. Working with Scrum you want to change habits inside your team: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.

Kanban – Incremental Improvements

Kanban is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum ;-) . In Kanban, you organize your work on a Kanban Board. There you have states which every work item passes through from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns starting from the right hand side based on the allocated capacity of each of the columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. Nothing else needs to be changed to get started with Kanban.

Kanban Leverages Work In Progress (WIP) Limits as Change Agent

For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to stay in a certain state. If the state is “full”, no new work can enter that state. The whole team has to help clear the filled up state first. That way your team will find out about bottlenecks in the progress simply by looking at the Kanban Board and is challenged to change the way they work to avoid such bottlenecks in the future. In that way, the WIP limit acts as change agent in Kanban.

Scrum vs. Kanban

Looking at both agile methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.


This post from Tobias Mayer at the”Agile Anarchy” blog.

Scrum and Kanban — different animals

On my last blog post Simple Scrum, Karl Scotland commented:

“Nice description. It also gives me a nice way of contrasting a Scrum and Kanban. Kanban says nothing about Roles, Artefacts or Ceremonies, but leaves the team to self-organise what works best. Instead, Kanban (as I describe it) suggests focussing on understanding the value stream, visualising it, limiting work in progress, establishing a cadence, and continuously improving […]“

Karl’s comment helped me to see clearly that any comparison between Scrum and Kanban is utterly pointless. It is like comparing a hammer with a screw driver, or an soufflé with a kangaroo. Which is better?

It was that phrase “value stream” that did it. It has always made me vaguely uncomfortable when I have heard it spoken in relation to software, and I wasn’t sure why. I have been thinking more about it, and I think I understand. There are two things.

This is a kanban (from

Firstly, I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas. Once you have mastered something, and go into building variations of it (e.g. web sites, or hand-crafted wedding dresses) then perhaps value-stream mapping comes into its own (there would need to be more similarities than differences). But before such time of repetition I suggest that to focus on a value stream is specious, and misleads people into believing that the creative process is mappable and repeatable. It is not.

Secondly, and more importantly, Scrum is a framework for organizational change It is people-centric. The focus of Kanban —as described here by Karl— is on business value. It is profit-focused. Focusing on profit will rarely transform an organization. Focusing on people and culture stands a better chance. The goal of Scrum —or at least, the goal of the Scrum Alliance, of which I am a member— is to transform the world of work. To do that, we must start with the individual, and we must focus on human values, not business values.

It has become clear to me that Scrum and Kanban are in place for different reasons. Sure, using Scrum you may increase your productivity and build better products (one would hope so!) and using Kanban may make people happier at work, but these are secondary concerns.

And lastly, a word for XP. If you are working with a software team, regardless of the process, and they are not using the principles of software craftsmanship suggested by XP, then please start there. Anything else will be a facade.