January 19, 2021
The Scaled Agile Framework, developed in 2011, is an online knowledge base that helps companies to work effectively and rapidly so that their products and services can reach the end-customer quickly. It is designed to help large organizations to surmount the difficulties of large teams working on complex projects.
How does SAFe work?
A large project is mapped into smaller tasks, which are tackled in incremental steps called “Sprints.” The team responsible for completing the Sprint works directly with the client and provides a timeframe based on each team member’s input. The client evaluates and gives feedback as each Sprint is completed, rather than wait for the entire project to be delivered. It helps the client be involved in the entire project from the initial stages, right up to the conclusion.
Problems with SAFe
Adopting the Scaled Agile Framework comes with a set of challenges. People tend to think that using SAFe will resolve all the issues that arise in project management. The truth of the matter is that organizations with fundamental problems in their functioning will continue to have problems, and sometimes these could get exacerbated. Here are some of the problems of SAFe that one must know about.
◦ Not having the right work environment
SAFe is designed for large-scale operations, and it is sometimes easy to overlook the most basic of considerations, which is the quality of coding. It is non-debatable that, before organizations commit to SAFe implementation, the company’s engineering practices should be thorough and up-to-date. Organizations that do not practice modern architecture, development, and testing techniques end up worse than before. Teams should also be well-equipped and believe in Agile practices. There should be a collaborative working environment that is happy to accept innovation. Without such a strong base, SAFe implementation is bound to be a disaster.
SAFe grants very little room for flexibility that may be needed for the way different organization functions. There is a lot of focus on planning, hierarchy, and standards. Once SAFe is implemented, it can affect the entire organization in one go. There is almost no option to keep some functions independent from this wave of change.
◦ Increased management layers
The workflow and the processes are complex by themselves; besides, there are several layers of management within each part of the process. In theory, it is to help each part have full control over their area of work. In practice, it slows down the entire workflow because of the different ways that teams can function and make decisions.
◦ Autocratic decision-making
Another problem with SAFe is that teams are viewed as groups having a delivery function and not a strategic group. For example: At the “Portfolio”- the highest level, SAFe supports the funding of an unlimited number of “Value Streams,” which are dedicated to supporting one or more solutions required by the customers. The funding is authorized by the “Lean Portfolio Management,” which also decides which Epics (large initiatives for a significant solution development) move into which value stream. It means that many decisions are made at the top-level, not by the most familiar people with the work.
◦ Overly complex
SAFe has a very complicated operation that even someone who has worked and researched for a long time cannot fully understand features. Despite the many checkpoints, it isn’t easy to get all the stakeholders to work harmoniously due to varying methods and values. It goes against the very basic Agile principle that “individuals and interactions are more important than processes and tools.”
◦ Lack of Role Flexibility
Team members in SAFe are given roles that are rigorously defined. Even when it makes sense, SAFe does not support the permanent or even temporary swapping of roles. There is not enough focus on training team members to handle their own needs but encourages dependence outside the team. Hence team members do not develop a sense of complete ownership of their tasks.
◦ Always the ‘Big Picture’
SAFe endeavors to focus on the big picture and not just get bogged down in details. On the other hand, this emphasis leads to longer planning and delivery cycles in the development phase. Therefore, it is contrary to the idea of what a Sprint is supposed to do: which is to deliver new products to the market in the shortest period.
◦ Definition of terms
“Customers” in SAFe are not, as one would think, the end-user of the product or service. There is a far broader definition that includes financing the value streams and other collaborators with a vested interest. It goes against commonly held design thinking principles where the focus is on what the consumer requires.
The term “Epic” has been in use before SAFe and meant a user-story (product specifications looked at from the users’ point of view) that was too large to be managed within one Sprint and needed to be broken down. SAFe defined an epic as “initiatives that are sufficiently substantial to warrant analysis and understanding of potential return on investment before implementation” The two definitions are completely different and can lead to confusion if not understood properly.
◦ Identifying and prioritizing Epics
Since Epics need to have a detailed analysis before moving along, projects in the pipeline should be tackled according to priority. Stakeholders have to come to the discussion table and agree upon the definition and the purpose of the epic. Reaching an agreement on which projects should go ahead can lead to tough outcomes.
◦ Estimating the duration of an Epic
Because SAFe involves large teams with several hundreds of people, the structure tends to have work done in large batches. Being able to estimate timelines is a crucial factor in the process. The duration of an Epic is calculated using inputs from external suppliers and the internal “Agile Release Trains” (ART – is a dedicated, full-time team that incrementally develops, delivers, and sometimes operates one or more solutions in a value stream). It requires extensive collaborative work and understanding of several data points, which can be pretty challenging.
◦ Too much focus on planning
“Program Increments” (PI) are a significant part of SAFe implementation. PI begins with PI planning. There are also pre-and post-planning activities. In theory, PI planning is a very good idea for people to work out the objectives to be delivered and focus on their dependencies on other teams. In practice, a lot of the planning is based on predefined features where assumptions are made, and the plans often become outdated because of new developments elsewhere. Many of the commitments made are locked during these meetings, and there is no scope to change these even when new information comes up.
◦ Retrospection is limited
Although planning and team retrospective is a major aspect of the SAFe framework, the effectiveness is quite low. It is impossible to expect members from the Program level to be able to attend team retrospectives consistently. Hence, the required changes cannot be actioned by the people who have the authority to do it. A lot of the retrospective time is spent on “assessment charts,” checking whether SAFe principles are being followed, rather than their effectiveness. The process, therefore, becomes more important than the result.
◦ Synthesis of existing concepts is confusing
Existing concepts like Scrum, Lean UX, DevOps have been incorporated into the SAFe framework. The synthesis, especially concerning applying lean and Agile principles, has not been straightforward. These principles have been tried, tested, and certified as effective. However, the result of the aggregation within SAFe is more confusing than effective.
◦ Published customer stories
There are more than 60 success stories of SAFe implementation on their official website. However, there are no published case studies done on projects that have not done so well, which shows that the presentation is highly one-sided and does not talk about the risk factors involved. It is important that organizations thoroughly research this framework’s potential downside before deciding whether it is worth implementing.
Here, we have tried to put together a comprehensive list of practical problems of SAFe. If not understood properly, SAFe would seem to be a project-oriented rather than product-oriented framework. A simplified explanation looks like the goal is to map out processes, features, and output, and then work towards delivering them on given deadlines, without much thought given to outcomes. Of course, this would not be what an evolved organization that believes in Lean and Agile principles wants to achieve. Skilled, experienced, certified SAFe practitioners the world over have helped overcome the initial challenges and lift their organizations to greater heights with Agile product development and lean-agile leadership.
Oh! We recently winded up one batch, but no worries. We have a few more in the coming weeks.
Just opt-in for the updates about dates, prices, and curriculum with your preferences!
We keep you posted about the course.
Business Certification Trainings in South Korea, CBAP Certification in Bangladesh, Angular JS Training in Norway, Extreme Programming XP Online Training in Gurgaon, ECBA Online Certification in Botswana, Business Case Writing Online Certification in Bafoussam, SAFe For Teams Certification in Port Moresby, CAPM Certification in Egypt
Certified Scrum Master(CSM®),Advanced Certified Scrum Master(A-CSM®), Certified Scrum Professional ScrumMaster(CSP-SM®), Certified Scrum Product Owner (CSPO®), Advanced Certified Scrum Product Owner (A-CSPO®), Certified Scrum Professional Product Owner(CSP-PO®), Certified Scrum Developer (CSD®), Certified Scrum Professional(CSP®), Certified Agile Leadership(CAL-I®,CAL-II®), Scrum Education Units(SEU®),Certified Scrum Trainer (CST®),Certified Enterprise Coach(CEC®), and Certified Team Coach(CTC®), are registered trademarks of Scrum Alliance®. SimpliAxis INC is a Registered Education Provider (REP) of Scrum Alliance®.
Profession Scrum Master (PSM-I®, PSM-II®, PSM-III®), Profession Scrum Product Owner (PSPO-I®, PSPO-II®, PSPO-III®), Profession Scrum Developer (PSD-I®), Scaled Professional Scrum(SPS®),Professional Scrum With Kanban(PSK-I®) , Prove your knowledge of Professional Agile Leadership(PAL-I®), Prove your knowledge of Evidence-Based Management™ (PAL-EBM®), Prove Your Scrum with User Experience Knowledge (PSU-I®) and Professional Scrum Trainer(PST®) are registered trademarks of Scrum.org®. SimpliAxis INC is a Professional Training Network member of Scrum.org®.
Certified Business Analysis Professional (CBAP®), Certification of Capability in Business Analysis(CCBA®), Entry Certificate in Business Analysis(ECBA®), Agile Analysis Certification(AAC®), Certification in Business Data Analytics(CBDA®), Certificate in Cybersecurity Analysis(CCA®), Certificate in Product Ownership Analysis(CPOA®) are registered trademarks of International Institute of Business Analysis(IIBA®). SimpliAxis INC is an Premier Level Endorsed Education Provider of IIBA®.
SAFe Agilist Certification (SA®), SAFe Program Consultant Certification (SPC®),SAFe Program Consultant Trainer Certification (SPCT®),SAFe Practitioner Certification(SP®),SAFe Release Train Engineer Certification (RTE®),SAFe Scrum Master Certification (SSM®),SAFe Advanced Scrum Master Certification (SASM®),SAFe DevOps Practitioner Certification(SDP®),Agile Product Manager Certification (APM®),Lean Portfolio Manager Certification (LPM®),Product Owner / Product Manager Certification (POPM®),SAFe Architect Certification (ARCH®),Agile Software Engineer Certification (ASE®) and SAFe Government Practitioner Certification (SGP®), Scaled Agile Framework® and SAFe® are registered trademarks of Scaled Agile, Inc.®. SimpliAxis INC is a Silver Partner of Scaled Agile, Inc®.
DevOps Foundation®, DevOps Leader®, SRE Foundation℠, SRE Practitioner℠, DevSecOps Foundation℠, Continuous Testing Foundation℠, Certified Agile Service Manager®, Continuous Delivery Ecosystem Foundation℠ and Value Stream Management Foundation® are registered trademarks of DevOps Institute. SimpliAxis INC is a Registered Education Partner (REP) of the DevOps Institute (DOI) ®. Read more...