The Scaled Agile Framework, pronounced “SAFe”, is a framework for implementing lean and agile methods at scale. It was pioneered by Dean Leffingwell and fully described in his book Agile Software Requirements. SAFe provides prescriptive guidance for the individual roles, teams, activities, and artifacts necessary to scale agile from the team to program to enterprise level.
SAFe’s guidance is divided into three layers, each aligned to a level of abstraction matched to project scope within an enterprise. Actionable work is driven top down through cascading backlog queues and a simple, well defined taxonomy.
The Portfolio layer defines a framework for managing an enterprise project portfolio. The portfolio is implemented as a backlog of business and architectural “epics”, high level narratives aligned to strategic investment themes. Approved epics are delivered to the Program layer for further exposition and scheduling for implementation.
The Program layer defines procedures for turning approved epics into proper product plans and is responsible for delivering a value stream to the organization. Activities include developing product visions, a backlog of high level “features” to be implemented, product roadmaps, and iterative release plans. Project features are batched up and delivered to the Team layer for implementation.
The Team layer prescribes a combination of Scrum management practices and XP technical practices to empower agile development teams to turn features into “user stories” and deliver working, valuable software in two weeks sprints.
Why You Really Should Care
So why am I raving about this? Agile has become the first choice for development teams building software, but true enterprise agile transformations are still rare. Adoption inside many enterprises has stalled due conflict with traditional waterfall business planning and budgeting processes. Here’s why I think SAFe can succeed at driving full scale enterprise agile adoption:
Simple. The epic–feature–user story taxonomy is the heart of this framework and the key to tracing efforts through these layers to achieve synchronization, collaboration and business value delivery. Its simple to learn and easy to teach – a key ingredient to cultural transformation.
Comprehensive. The layered abstractions chosen for SAFe provide the just the right amount of focus at the executive, product management, and development team levels. The roles and procedures are well defined and cover the complete set of activities needed to manage a portfolio of enterprise IT projects. SAFe will educate and push agile up into the very heart of the enterprise.
Actionable. SAFe provides concrete procedures and detailed steps on how to get each layer up and running. It’s very real, very approachable, and very doable.
Well Documented. Leffingwell’s Agile Software Requirements book is in truth a playbook for enterprise agile transformation. It describes every detail of the SAFe framework and is one of the best written technical books I’ve read in years. Dean and his associates have also done an outstanding job documenting and “open sourcing” the framework through it’s public website – scaledagileframework.com.
Proven in the Field. The framework has been through numerous iterations, and has evolved through a number of large scale adoptions at real world enterprises, large and small. The latest version published on the web site (v2.5 as of this blog post) has been validated by these field implementations and all the major ALM software vendors have either adopted it directly or facilitate an implementation of SAFe within their product.
I honestly haven’t been this excited about a SDLC methodology in years (I read Dean’s book cover to cover in two days – a rarity for a technical book). I see SAFe as a natural and necessary evolution of Agile upwards into the enterprise to fill a missing void. I believe it will quickly become the foundation for many of our client engagements.
Note: Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC.
I wanted to shine a spotlight on one of our local development studios this week and share some of their story.
Pig Out Productions has released the first of their many games to the Windows 8 store.
I Want My Mummy is a 70 levels of rock breaking, TNT exploding physics puzzle fun. You tap on rocks to destroy them and try to get your mummy on the black landing platforms. Along the way, exploding bombs will launch your mummy through the air, knocking over walls and triggering more explosives and mayhem. You'll also have to deal with rocks that defy the laws of gravity and float away.
Pig Out Productions is a game studio based in Rolla, Missouri founded by William Garrett. Not your typical software developer, William’s preferred tools of choice are GameSalad and Photoshop. He’s completely self taught and specializes in casual, family oriented games with broad appeal. He works with a local artists and musicians to develop and refine his game concepts. As each game crystalizes, his children become his test audience. If sees them picking them up and playing over and over again, he knows has hit on his hands.
Over the last few years, Pig Out Productions has published a solid collection of great games for the iOS and Android platforms. William and his talented team are working feverishly to bring them to Windows 8 for us to enjoy. Look for them in the Windows 8 store in the coming weeks.
As always, stay tuned to my twitter feed for Windows 8, Windows Azure and other Microsoft developer announcements, updates, and links: @clinted
While working on my latest Windows Store application, I found that I needed a better mental model of the relationships between the framework classes. Here are some quick sketches that cover the core objects and their interactions during application launch.
Core Objects
The diagram below shows the core objects common to all store applications:
An App class derived from the framework’s Application base class is the starting point. It represents the running process for the application and exposes basic events for startup and shutdown, as well as several other special events triggered by the operating system.
The sealed Window class represents the core container window created by the operating system to host the application’s user interface. It exposes several properties and events related to visibility and sizing. It acts as the host for the visual controls that compose the application.
The Frame class is a visual content container. It is attached to and completely fills the core Window object. It hosts and manages the lifetimes of the individual Page objects that form the user experience of an application. It provides a navigation framework with full backward and forward history stacks to allow movement between pages using a familiar browsing metaphor.
You can see an expanded view of these objects with their attributes and methods here:
Application Launch
The sequence diagram below shows the basic launch steps for a simple store application with a single Main page:
When a user launches the app, it triggers a call to the overloaded OnLaunched() event in the App class. This method instantiates a new root Frame object and attaches it to the framework’s current Window (there’s only one for the newly launched application).
Once the Frame is attached, a call to Navigate( typeof(MainPage) ) triggers the creation of the first page, fills the frame with it, and places it in the navigation history stack. It’s important to point out that the Frame’s navigation framework takes care of instantiating the requested pages, optionally reusing them if desired.
After the Frame is set up and the first page has been primed, a final method call to Window.Current.Activate() brings the application window to the forefront and shows it to the user.
That’s a quick tour of the Windows Store app model to show the fundamental objects and how they interact with each other as the application starts up.
Note: These models are based on a C# + XAML based application. The core object model is fundamentally the same for JavaScript + HTML5, but there are some differences in event names and object interactions due to language and runtime differences. I’ll show the JavaScript + HTML 5 versions of these same models in a future article.
As always, stay tuned to my twitter feed for Windows 8, Windows Azure and other Microsoft developer announcements, updates, and links: @clinted