My article this week is about SAFe, which stands for Scaled Agile Framework.
The Scaled Agile Framework is a method that can be applied to Agile software development and is created by Dean Leffingwell. Dean is also known as the author of a few books such as “Agile Software Requirements” and “Scaling Software Agility.”
For a little more than a year now I have been working in environments where SAFe is being utilized or evaluated. I consider myself fortunate to have been introduced to SAFe last year. I began to realize early that SAFe was a process that was easy for me to understand.
To date, I have explained SAFe to people more times than I can remember. And each time I do, I often get the same response from the person I am speaking to. The response is akin to a deer in headlights.
So what has been my approach for explaining SAFe?
I am a pretty consistent guy when it comes to explaining things and my favorite thing to do when explaining SAFe is to break out a copy of the “Big Picture.” But before I do, I always remind myself to preface the picture with some sort of phase such as: Now I am going to show you a picture but it is a complex picture that I will break down for you so don’t get intimidated when you see it.
Then I said to myself, why must I preface a picture like that. It most certainly is not because I question the intelligence of the person I am speaking to. But yet I still find the need to preface my discussion.
This got me thinking!
I, myself, would notice that I keep going back to the Big Picture to define where something was or when something takes place or who something is impacting or responsible for. I keep asking myself the same questions and that inspired me to do something about it.
So keeping within the great minds of every Agilest out there, I “decomposed” the Big Picture. But I did not do this alone!
Last weekend, I got together with a very good friend of mine from a past engagement and we worked tirelessly for close to 20 hours making a best effort to decompose SAFe’s Big Picture.
During our working session we created several artifacts that can be used to help explain SAFe to someone who wants to know more about it.
The approach we took was more of a technical approach, one that I would say, business users and architects alike might prefer, because not only does our decomposed picture show all the pieces but also it puts the pieces in order of flow with brief descriptions around each one.
Before I introduce this picture to you for your comments and feedback, I would like to give a special thank you to my friend Rene Tietsort for getting together with me and providing guidance and assistance.
Our SAFe Big Picture (decomposed) diagram begins with a Business layer that has been added to the diagram simply as a starting off point. This layer will kick-off the flow of the rest of the diagram. (Click image to view larger)
To make this section brief we start out by saying there is some new idea that an executive might have or a new mandate or possibly some end of life scenario the business is about to encounter on a piece of software or system. Regardless, this event will spawn a project.
We don’t mean to say a project is now active, what we are saying is that the idea for a new project is forming. We then begin to think about and answer the question, how much value would this project have to the business.
If it is determined worthy to pursue then the business leader will begin to frame their vision and at a very high level start to form a roadmap for when to execute on that vision.
The Business section of our diagram will now lead into the very top layer of SAFe, the Portfolio Layer.
The Portfolio Layer in SAFe has a very high-level but specific purpose. Here we identify certain Value Streams. These streams are areas of importance to the business and are derived from the Business Values.
The next piece to be identified is which lines of business would be impacted or affected by this business change. Program Management represents a Line of Business (LOB) and will then create Investment Theme work item types.
While the Themes are being established the Epic Owner and Enterprise Architect work together to define the Business Epics and Architectural Epics. Architectural Epics are ones that continue indefinitely, whereas a business Epic will have a specific start and end date for completion.
All of the Themes and Epics are then combined into a Portfolio Backlog, which is the final step in our diagram before we cross over into the Program Layer.
Part 3 would be Program and Part 4 would be Team. I am sure you may have figured that out by now. I won’t get into specific descriptions for Part 3 and 4 because if the diagram is good, then I believe the user should be able to understand it without framing descriptions.
I will bring to your attention one piece that is drawn out in the Program Layer. When you look at the diagram, you will see two section of colored underlay below the flow boxes.
The top box represents week 0A and the bottom colored box represents week 0B. These weeks are not from the SAFe model as they are called but the work done during these weeks is directly from the SAFe model.
Next week I will provide you all with a SAFe interpretive calendar and on this calendar I will draw out weeks 0A and 0B so you can see them in their context.
FOOTNOTE: This diagram is our (Rene and Mike) interpretation of the Scaled Agile Framework Big Picture. While the picture is ours, the process explained belongs to Dean Leffingwell. Dean himself was not involved in the making of this picture and has not been asked to endorse it, so if there are areas that are missing, defined poorly, not clear, not correct or skewed in any way, please let me know and we will correct the diagram. Again, this is our interpretation based on what we derived from the http://www.scaledagileframework.com website.
Click on the diagram below for a blown up version.