Scaled Agile Framework

What is SAFe, the Scaled Agile Framework, and why should you be interested in it?

To begin, we need some background. The earliest methodology applied to software engineering is known as the ‘waterfall’ model, becuase it’s often represented as a series of steps the development process goes through, and when represented in a GANTT chart style those steps do indeed look something like a waterfall as you can see from the top right of the image below.

The image comes from Winston Royce’s 1970 book “Managing the Development of Large Software Systems”, a well-known and respected treatment of the subject.

The waterfall model served very well for at least a decade after Royce’s book came out. Systems of the time were much more constrained by CPU speed and system resources than their modern equivalent, so simply had to ensure that everything was planned and built as a single start-to-finish project. When this worked well, it worked extremely well. Some systems/applications designed and built using this model may still be found in banking, government, defense, finance and other industries where they are still performing business critical functions.

Sounds like it wasn’t broken, so why did it need to be fixed?

As computing resources became more widely available the use of applications extended beyond so-called ‘back office processing’. This means more complex applications being developed against changing business requirements which resulted in a series of high-profile failures. Because the initial snapshot of requirements was often incomplete or unclear, or changing circumstances forced changes in scopre or requirements part way through the project, many systems were delivered late, incomplete, wildly over budget or in the worst case simply never delivered a complete, working system at all.

There will always be circumstances where the exhaustive, waterfall based approach is best. You don’t want a medical device running on a beta release of software, and that’s not a good idea for things like power generation and distribution or any other high-risk or potentially life threatening situation.

On the other hand, a word processing system with a minor bug in it isn’t going to kill anybody or black out the power grid. That minor bug might be a nuisance, but on balance the users will prefer an application that works NOW with some updates LATER rather than waiting forever for a ‘perfect’ product.

IBM learnt this lesson the hard way with the OS/2 desktop operating system. Conceived around the same time as Microsoft Windows, OS/2 was a much better take on the same idea of a graphical desktop running on PC-compatible hardware but the engineering team kept delaying release to get it ‘right’‘. Early versions of MS Windows were buggy and fragile, causing phrases like ‘Blue Screen of Death’ and ‘three-finger reset’ to enter the language of everyday users but it did most of the things it needed to do most of the time, and enough of the time that users accepted the tradeoff. Windows became mainstream and even though OS/2 was arguably the better product it arrived too late, and by the time it did arrive Windows had moved on to include more features (and bugs) … but enough people were prepared to accept ‘good enough for most cases’ over ‘perfect’, and the rest is history.

It’s the same thing with business applications. The modern business world has reached the point where the concept of ‘the computers are down, so we’re doing things manually’ won’t fly any more. Software applications must meet the immediate needs of the users and organization, they must do it well enough to be usable and reliable, and those features must be delivered early enough for the system to still be of use when implemented.

The Agile Revolution

The Agile Manifesto seeks to address many of the causes of expensive delays and rework that result in late delivery, incomplete delivery or simply failure to deliver working systems.

12 principles underpin the manifesto:

1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months).
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals, who should be trusted.
6. Face-to-face conversation is the best form of communication (co-location).
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

When done well, Agile software delivery works well and is widely adopted, and usually preferred, as a method for getting quality software in the hands of users.

LEAN software engineering

LEAN software engineering grew from an Agile-focused subculture which looked at physical manufacturing and in particular the Toyota Production System. They concluded that seven lean principles should be applied to software engineering teams, and that these were closely aligned with the initial 12 Agile principles.

1. Eliminate Waste
2. Amplify Learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. Optimize the whole

DevOps for the win!

The next evolution in thinking was to remove the disconnect between fast-moving software development and what were often top-down, rigidly defined (often using a structure like ITIL) processes for making relases or changes into production environments.

In the DevOps model, development of new systems or features and the management of those features in a production environment are handled in a much more tightly integrated and closely-coupled working model to facilitate speed of release whilst at the same time maintaing control of reliability and quality.

The Problem of Scale

Agile / Lean / DevSecOps based teams work very well when the scope is small enough to be manageable. If the scope or scale of a software delivery project is too broad, then the number of people involved becomes hard to manage, and coordination between major components starts to hinder rather than help the goal of getting working softare into the hands of users.

Some organizations have promoted ‘hybrid’ models with Waterfall-style planning cycles trying to coordinate Agile delivery teams. It’s fair to say that most of these approaches have been either poorly performing or downright discredited, because the linear or waterfall elements of the hybrid approach place artificial constraints on Agile delivery.

The cooperative, collaborative environment underpinning Agile delivery methods begin to break down when teams get too large: the amount of time spent updating everyone and coordinating efforts begins to overshadow the amount of time spent on delivery.

Enter the SAFe

The Scale Agile Framework started from a belief that “better software and systems make the workd a better place”98236

aligned to a mission which, by version 5 of SAFe, is stated as “To enable the business agility that is required for enterprises to compete and thrive in the Digital Age”

SAFe seeks to create and integrate the business planning and management processes which, in turn, will drive multiple Agile development teams to create and deliver to the business, stakeholders and customers.

SAFe customer stories are a series of case histories from organizations like Porsche, Deutsche Telekom, Northrop Grumman and the U.S. Air Force showcasing benefits that include:

• 20 – 50% increase in productivity
• 25 – 75% improvements in quality
• 30 – 75% faster time-to-market
• 10 – 15% increase in employee engagement and job satisfactions

SAFe builds on seven core competencies of the lean enterprise

Lean-Agile Leadership – Advancing and applying Lean-Agile leadership skills that drive and sustain organizational change by empowering individuals and teams to reach their highest potential

Team and Technical Agility – Driving team Agile behaviors as well as sound technical practices including Built-In Quality, Behavior-Driven Development (BDD), Agile testing, Test -Driven Development (TDD) and more

Agile Product Delivery – Building high-performing teams-of-teams that use design thinking and customer-centricity to provide a continuous flow of valuable products using Dev(Sec)Ops, the Continuous Delivery Pipeline and Release-on-Demand

Enterprise Solution Delivery – Building and sustaining the world’s largest software applications, networks and cyber-physical solutions

LEAN Portfolio Management – Executing portfolio vision and strategy formulation, chartering portfolios, creating the Vision, Lean budget and Guardrails as well as portfolio prioritization and roadmapping

Organizational Agility – Aligning strategy and execution by applying LEAN and systems thinking approaches to strategy and investment funding, Agile portfolio operations and governance

Continuous Learning Culture – Continually increasing knowledge, competence and performance by becoming a learning organization committed to relentless improvement and innovation

The Key Take-away

Agile / LEAN / DevOps / DevSecOps are focused on how to efficiently build and deliver working software that adds value for the business stakeholders and users.

The Scaled Agile Framework (SAFe) focuses on creating a business and organizational culture which is better equipped to take advantage of Agile delivery and to operate in a way where the Agile delivery model is set up for success rather than being pulled towards failure by incompatible or outdated planning at the strategic level.