SYS-CON MEDIA Authors: Yeshim Deniz, Liz McMillan, Elizabeth White, Maria C. Horton, Andy Thurai

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
CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City.
Blockchain has shifted from hype to reality across many industries including Financial Services, Supply Chain, Retail, Healthcare and Government. While traditional tech and crypto organizations are generally male dominated, women have embraced blockchain technology from its inception. This is no more evident than at companies where women occupy many of the blockchain roles and leadership positions. Join this panel to hear three women in blockchain share their experience and their POV on the futu...
"At the keynote this morning we spoke about the value proposition of Nutanix, of having a DevOps culture and a mindset, and the business outcomes of achieving agility and scale, which everybody here is trying to accomplish," noted Mark Lavi, DevOps Solution Architect at Nutanix, in this SYS-CON.tv interview at @DevOpsSummit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embr...
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...
Apptio fuels digital business transformation. Technology leaders use Apptio's machine learning to analyze and plan their technology spend so they can invest in products that increase the speed of business and deliver innovation. With Apptio, they translate raw costs, utilization, and billing data into business-centric views that help their organization optimize spending, plan strategically, and drive digital strategy that funds growth of the business. Technology leaders can gather instant recomm...
In an age of borderless networks, security for the cloud and security for the corporate network can no longer be separated. Security teams are now presented with the challenge of monitoring and controlling access to these cloud environments, at the same time that developers quickly spin up new cloud instances and executives push forwards new initiatives. The vulnerabilities created by migration to the cloud, such as misconfigurations and compromised credentials, require that security teams t...
Serverless Architecture is the new paradigm shift in cloud application development. It has potential to take the fundamental benefit of cloud platform leverage to another level. "Focus on your application code, not the infrastructure" All the leading cloud platform provide services to implement Serverless architecture : AWS Lambda, Azure Functions, Google Cloud Functions, IBM Openwhisk, Oracle Fn Project.
AI and machine learning disruption for Enterprises started happening in the areas such as IT operations management (ITOPs) and Cloud management and SaaS apps. In 2019 CIOs will see disruptive solutions for Cloud & Devops, AI/ML driven IT Ops and Cloud Ops. Customers want AI-driven multi-cloud operations for monitoring, detection, prevention of disruptions. Disruptions cause revenue loss, unhappy users, impacts brand reputation etc.
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Serverless Computing or Functions as a Service (FaaS) is gaining momentum. Amazon is fueling the innovation by expanding Lambda to edge devices and content distribution network. IBM, Microsoft, and Google have their own FaaS offerings in the public cloud. There are over half-a-dozen open source serverless projects that are getting the attention of developers.
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embr...
The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.