Scaled Agile Framework (SAFe) LiveLessons Video Series Review

This is a review of the Scaled Agile Framework (SAFe) LiveLessons video series. Below are a list of lessons covered.

Lesson 1: Introducing the Scaled Agile Framework
Lesson 2: Thinking Lean and Embracing Agility
Lesson 3: Applying SAFe Principles
Lesson 4: Implementing an Agile Release Train
Lesson 5: Plan a Program Increment
Lesson 6: Execute a Program Increment
Lesson 7: Implementing the Agile Portfolio
Lesson 8: Scaling Leadership—A Learning Journey

The Review
The Agile buzzword has done a lot of damage, but so has SOA, Lean, Scrum, Cloud, as well as one of the latest buzzwords- DevOps. The true processes and architectures that those buzzwords represent, when used in the right context, and the right way, have made the software development world a much better place to be.

I have said it at least a hundred times, so one more time won't hurt- none of these processes and architectures are intended to make building software easier, they are intended to enable you to succeed. The one big requirement for success with these processes and architectures is that teams need to have a lot of experience and skills. One way to learn about the skills needed are through books and training videos like this one.

SAFe was the first enterprise level agile process and it is still the most comprehensive and complete enterprise level agile process. What baffles me is the number of enterprises I have been in that have not come close to implementing 10% of the needed process activities at the different levels of the enterprise, yet they call themselves agile and lean. The one thing this video series brings to light is just how complex and advanced agile processes are. In his book on SAFe, the video presenter says, "it is not easy, it is agile".

I liked this whole video series. There is a ton of great information in it and if you look into the references you will learn a ton. Some of my favorite topics were the SAFe House of Lean, SAFe principles, coverage of the agile manifesto, limiting work in process (WIP), WSJF (Weighted Shortest Job First), Agile Release Trains (ART), budgeting, and scaling leadership.

The SAFe House of Lean coverage is great. The presenter uses a different parts of a house to help visualize Lean. The roof is the goal - Value, the three pillars are - Respect for People, Product Development Flow, Kaizen, and the foundation of the house is Leadership.

Most of the house titles are self explanatory except Kaizen. Kaizen represents driven, relentless reflection and continuous improvement. Organizations make small, steady improvements to effect significant, lasting change over time.

The SAFe Principles are a great compilation of Lean and Agile principles that SAFe is built upon. They are listed below.

Take an economic view
Apply systems thinking
Assume variability, preserve alternatives
Manage risk and efficacy with fast, synchronous learning cycles
Develop systems incrementally, integrate and test frequently
Facilitate flow by reducing batch sizes, managing queue lengths, and limiting WIP (work in process)
Base milestones on objective evaluation of working systems
Synchronize with cross-domain planning and collaboration
Unlock the intrinsic motivation of knowledge workers
Decentralize decision-making

The presenter does a great job of covering the agile manifesto. He points out that they did not say "do not do the things on the right" but rather find the things on the left more important. One of the most damaging thinks the agile manifesto has done is allow teams to interpret it to mean no more documentation and no more architecture is needed.

I do documentation, proof of concepts, and architectural diagrams because it helps me think through the process of how the artifacts will actually be built. The architectural artifacts also provide the Rosetta Stone of the project between the technical and nontechnical team members. Without the exercise of documenting I cannot do due diligence with respect to correctly creating the simplest yet most effective solution. From what I've seen nobody can. That is of course unless they've done the solution many times in the past. I have been fighting for years to get architecture and documentation back into the processes that need it. Thank goodness the agilists are finally speaking out on the topic. Processes like SAFe and DAD (Disciplined Agile Delivery) have grounded the agile world back in reality, and they do not pull punches.

Too much work in process (WIP) is a huge problem, especially in a command and control environment. They have no concept of context switching, or the damage it does, and they think the more they pile on the better they are managing. Most days I see people running around like chickens with their heads cut off, completely ineffective and getting nothing done, except moving onto the next fire. I am actually two or three days ahead, every day I take off, because I'm not there to fight fires and have tasks added to my queue. Every project that is done is done because it finally becomes a fire. Systems that should've been taken off-line years ago are finally being taken off-line because they will no longer run. Most of these issues can be shown to relate back to work in process, and never having the time to actually complete tasks and complete them right.

I really like the way SAFe emphasizes leadership and not management- "SAFe Lean-Agile leaders are life-long learners and teachers who help teams build better systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking, and Agile software development."

I am not a manager, but as an architect I am always managing. If I simply managed, no one would do what I ask. I learned a long time ago I must be willing to jump in and do first what I expect others to also do.  It was the only way I could get my developers to do documentation, learn patterns, and be willing to learn to deal with complexity by working towards simplicity.  I had to do it first.  It was a small part of the mentoring process needed to implement a SDLC on the projects I led.

It seems to me agilists like to assume all employees can be great team members because of their need for cross functional teams filled with people that are generalists. SAFe says agile team members is consisting primarily of developers and testers, but may include other necessary roles as well (e.g., technical lead, system architect, technical writer, etc.), which I agree with. Specialists are needed in agile environments more than they were in traditional SDLCs. A system of any complexity must have the architecture in place to support rapid change, which means you better have an architect that considers modifiability one of the most important quality attributes. Enabling modifiability while not sacrificing performance and simplicity is not easy.

I cannot stand the saying "There is no such thing as a bad employee, just bad managers". That seems to be the theme that all agilists continue to stick with, or they just avoid the topic of management altogether. In my experience a bad manager can shut down good employees, they can be inexperienced enough to hire bad employees, and they can completely destroy an environment, but there are also people (workers) that are, or have become, unteachable.

I won't go into much on the topic, but I do think SAFe should start providing some guidance on it. All I will say is you must accept that everyone will not survive the transition to an agile environment and that is ok. Change is change, and it is the responsibilities of that position that are changing. If the employee filling the position changes, great. If not, you change the employee in that position. There are no other options.

Don't get me wrong, management can do much more damage than bad employees. I have worked with about 5 developers that I could trust to know more than me about structuring code, know the nuances of the languages we were using, and have work done before they are asked to do it. In the environment I was in with the worst managers I have ever experienced, I witnessed one of them simply crushed.

Sometimes it is necessary to break the will of a young talented but stubborn employee, but you should never break their spirit. When you break their spirit you change something so foundational within their core that they end up undependable and dangerous. They become an insider threat that needs to move on so they can reclaim their dignity and passion.

The presenter provides nice coverage of long term planning. Although it is nice to think you do not need to have any long term planning in an agile process, you cannot do without it. Architecture requires long term planning in order to put a framework in place that allows for agility. An architecture that does not support change, shuts you down before you get started.

There are three parts on Agile Release Trains. These are teams of teams created at the program level that are responsible for delivering increments of value in a value stream. The three parts are Implementing an Agile Release Train, Plan a Program Increment, and Execute a Program Increment.

There is a lot on budgeting and it is rather radical compared to how I see budgeting done at most places. I see it fudged, shoved, twisted, and stretched to make it look like it is working, but it is just a hoax. Pay very close attention to the presenter, because odds are your budgeting does't work either, and trying something new cannot really hurt.

WSJF (Weighted Shortest Job First) is a great process for figuring out what you should do next. It is a comprehensive model for prioritizing work based on the economics of product development flow. WSJF is calculated as the Cost of Delay divided by job duration.

Leadership was the topic of the last module. The best leader I ever met was a project manager I worked with years ago, 15 years or so ago. My first project with her was to develop a navigation system for a fairly massive web site that was backed by a custom built administration tool. It housed GE Fanuc Automation Corporation's complete inventory.

My meeting with the company's developers to go over the requirements for the navigation system ended with me telling them it was not possible to build it the way they designed it. They said, figure it out. I said that could take a very long time. Their response was, your contract is 6 months and renewable so who cares. Just make sure you bill the right account. That was the attitude of everyone I had met their up to that point, but I had not worked with her prior to this.

The project manager came back to my desk everyday asking when it would be done, and I said "I do not know", she looked at me weird and walked off. After 2 weeks of that routine I told her not to ask me about work anymore. If she wanted to talk about the weather, or her weekend, fine - but stop asking me when it will be done. She looked at me like she wanted to slap me and then walked off.

She came back a few hours later and asked me why I said that. I told her it was because I told you it was impossible to build the way you want it, and you told me to do it anyway no matter how long it takes. She asked me to explain. Apparently the internal development team had not told her what I had told them.

She asked me how it should be done. I drew a few diagrams, and explained why it could not be done the way they wanted, but showed her how it could be done, and still meet all the customer's demands. She asked how long that would take and I said 3 weeks. She said do it, and I did. It was fully tested and ready for production promotion in 3 weeks.

That set in motion a new way of doing things at that company. The business had been telling her she needed to have it done in 2 weeks from the beginning of this ordeal. The dates came and went until I told her 3 weeks. She told them 3 weeks, they said no 2, she said sorry 3, and we delivered in 3 weeks. The next thing they said they wanted in 1 month. She asked me how long and I said 2 months. She told them 2 months. They were not at all used to this behavior, but after we delivered several projects in the time we promised, the business started trusting our team.

That sounds like a ho-hum story, but what followed was the development of a cross functional team that was completely transparent with the business, allowing the business to be completely transparent with the client. Over the next year and a half we developed iteratively, creating use cases, doing proof of concepts, requirement specifications, architectural diagrams, and had a blast. We did code reviews by having the whole team try to find issues with the code, if they found a certain amount of issues, the team member being reviewed had to buy the team ice cream.

We made deliveries every few weeks, which was fast enough to keep new requirements in the next release and had refactored the code so that it was very malleable and could be easily changed and tested. We achieved the state of agility. Keep in mind that agile is a state of being, not a process, not a set of development practices, not a way of budgeting, and not an architecture. All those things must be done in a certain way in order to achieve an agile state on a project.

Where did we learn how to do all that? Our team used 4 primary books to guide us - Managing Software Requirements: A Unified Approach, Software Architecture in Practice, Design Patterns: Elements of Reusable Object-Oriented Software, and Applying UML and Patterns. Two of them are now available in their third edition. Software Architecture in Practice - Applying UML and Patterns, and Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.

In case you don't know- Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise is all about SAFe.

The video covers three leadership styles - Leader as Expert, Leader as Conductor, and Leader as Developer. The presenter goes over the characteristics of each type, and the challenges each type has. He covers a ton of other valuable information as well.

I liked keeping the SAFe web site up while going through the videos. Following the topics on the site helped me get familiar with the current release of SAFe. I read the book a few years ago and still keep it handy, but the team developing SAFe has been hard at work adding new material. When I read the book, this site was just the process picture and some release dates, now it is a huge repository of valuable information.

The videos cover a bunch of valuable templates. Following along on the site allowed me to grab them as they were being covered.

I also recommend doing the exercises as the presenter asks you too. It really helps to do them because it makes you think the way the presenter wants you to think. Just watching him do them is good, but doing them yourself helps you absorb the topic more.

Do not make the mistake of thinking that you can take SAFe as is and implement the process in your enterprise. What you find here is the first thing needed for software process engineering, a repository of assets, principles, practices, activities, and patterns you can use to instance a process. The second half is instancing the process in your environment. Think of it like a module of classes, some of them he would override, some of them you would use as is, some of them you would not need to use, and you would add your own functionality.

The Scaled Agile site provides Enterprise SAFe which allows organization to customize SAFe. I used EPF (Eclipse Process Framework) to build a process for the State of Pennsylvania using material from Scott Ambler, SEI, Sparx, Microsoft Pattern and Practices group, and baseline processes like OpenUP and Scrum so I know what it should do, but have not had the opportunity to use or see it in action yet. I just wanted to point it out.

Over all I don't think you can afford not to watch this video series if you are planning on introducing agile processes at an enterprise level. Even if you aren't, watching the series will provide you with a tons of tools on teamwork and leadership. I have watched several parts of it several times. Get more information about the videos here.