SYS-CON MEDIA Authors: Stackify Blog, Zakia Bouachraoui, Elizabeth White, Pat Romanski, Liz McMillan

Blog Feed Post

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, but 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.

Read the original blog entry...

More Stories By Tad Anderson

Tad Anderson has been doing Software Architecture for 18 years and Enterprise Architecture for the past few.

Latest Stories
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
10ZiG Technology is a leading provider of endpoints for a Virtual Desktop Infrastructure environment. Our fast and reliable hardware is VMware, Citrix and Microsoft ready and designed to handle all ranges of usage - from task-based to sophisticated CAD/CAM users. 10ZiG prides itself in being one of the only companies whose sole focus is in Thin Clients and Zero Clients for VDI. This focus allows us to provide a truly unique level of personal service and customization that is a rare find in th...
Signs of a shift in the usage of public clouds are everywhere. Previously, as organizations outgrew old IT methods, the natural answer was to try the public cloud approach; however, the public platform alone is not a complete solution. Complaints include unpredictable/escalating costs and mounting security concerns in the public cloud. Ultimately, public cloud adoption can ultimately mean a shift of IT pains instead of a resolution. That's why the move to hybrid, custom, and multi-cloud will ...
Docker and Kubernetes are key elements of modern cloud native deployment automations. After building your microservices, common practice is to create docker images and create YAML files to automate the deployment with Docker and Kubernetes. Writing these YAMLs, Dockerfile descriptors are really painful and error prone.Ballerina is a new cloud-native programing language which understands the architecture around it - the compiler is environment aware of microservices directly deployable into infra...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace....
Between the mockups and specs produced by analysts, and resulting applications built by developers, there exists a gulf where projects fail, costs spiral, and applications disappoint. Methodologies like Agile attempt to address this with intensified communication, with partial success but many limitations. In his session at @DevOpsSummit at 19th Cloud Expo, Charles Kendrick, CTO at Isomorphic Software, presented a revolutionary model enabled by new technologies. Learn how business and develop...
Using serverless computing has a number of obvious benefits over traditional application infrastructure - you pay only for what you use, scale up or down immediately to match supply with demand, and avoid operating any server infrastructure at all. However, implementing maintainable and scalable applications using serverless computing services like AWS Lambda poses a number of challenges. The absence of long-lived, user-managed servers means that states cannot be maintained by the service. Lo...
Serverless applications increase developer productivity and time to market, by freeing engineers from spending time on infrastructure provisioning, configuration and management. Serverless also simplifies Operations and reduces cost - as the Kubernetes container infrastructure required to run these applications is automatically spun up and scaled precisely with the workload, to optimally handle all runtime requests. Recent advances in open source technology now allow organizations to run Serv...
GCP Marketplace is based on a multi-cloud and hybrid-first philosophy, focused on giving Google Cloud partners and enterprise customers flexibility without lock-in. It also helps customers innovate by easily adopting new technologies from ISV partners, such as commercial Kubernetes applications, and allows companies to oversee the full lifecycle of a solution, from discovery through management.
Docker is sweeping across startups and enterprises alike, changing the way we build and ship applications. It's the most prominent and widely known software container platform, and it's particularly useful for eliminating common challenges when collaborating on code (like the "it works on my machine" phenomenon that most devs know all too well). With Docker, you can run and manage apps side-by-side - in isolated containers - resulting in better compute density. It's something that many developer...
With the rise of Docker, Kubernetes, and other container technologies, the growth of microservices has skyrocketed among dev teams looking to innovate on a faster release cycle. This has enabled teams to finally realize their DevOps goals to ship and iterate quickly in a continuous delivery model. Why containers are growing in popularity is no surprise — they’re extremely easy to spin up or down, but come with an unforeseen issue. However, without the right foresight, DevOps and IT teams may lo...
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud host...
Take advantage of autoscaling, and high availability for Kubernetes with no worry about infrastructure. Be the Rockstar and avoid all the hurdles of deploying Kubernetes. So Why not take Heat and automate the setup of your Kubernetes cluster? Why not give project owners a Heat Stack to deploy Kubernetes whenever they want to? Hoping to share how anyone can use Heat to deploy Kubernetes on OpenStack and customize to their liking. This is a tried and true method that I've used on my OpenSta...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rathe...
Emil Sayegh is an early pioneer of cloud computing and is recognized as one of the industry's true veterans. A cloud visionary, he is credited with launching and leading the cloud computing and hosting businesses for HP, Rackspace, and Codero. Emil built the Rackspace cloud business while serving as the company's GM of the Cloud Computing Division. Earlier at Rackspace he served as VP of the Product Group and launched the company's private cloud and hosted exchange services. He later moved o...