With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles. Out of a wide range of topics, you can choose to learn from the real-world experiences by practitioners in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc.
Various business owners let small groups of people having similar kinds of work or goals in their organizations set up their own goals and design products. They strive to achieve success in this manner by giving freedom of expression to their employees. They apply Agile methods like Scrum and Kanban for this purpose. And these Agile methods work very well when the group is small. However, large companies also wanted to use Agile methods extensively in their organizations for large groups, departments, or cross-functional teams. But they faced trouble because of the limitations of Agile. Due to this, Dean Leffingwell and Drew Jemilo released SAFe® in 2011 to help large organizations meet customer requirements in a better way.
SAFe® is used to scale the Agile methods at a more extensive level. Transforming the thought process and working in a large group is difficult. The motivation in the group is not consistent, and the members of the large group may be too used to following the instructions of their superiors and may not be in the habit of taking the initiative or working independently. This is where SAFe® steps into it. It allows Agile to be scaled to suit the requirements of a large group or enterprise. But scaling Agile is by no means an easy task, particularly for a large group of people. It poses many difficulties to even those Agile Developers with a lot of experience. Many people find SAFe® quite helpful, but at the same time, many find implementing SAFe® troublesome.
To some extent, it is true. Companies do face SAFe® Agile issues. Let's examine some of the common problems with SAFe®.
There are many Agile methods, but SAFe® seems more inflexible than others. The approach is rigid to the extent that it leaves no scope for modification or change, so you can't customize it according to your company's specific requirements. More often than not, in SAFe®, the team members stick to their assigned roles only because there is no room for them to experiment. On the contrary, in other Agile methods, the team members flourish because they are the owners of their tasks and are asked to take responsibility for their goals. They are allowed to use their knowledge, effort, and skills in different ways for the organization's benefit. Scaled Agile Framework confines team members to their specific roles, not giving them much flexibility or freedom.
Unlike other Agile frameworks, decision-making in SAFe® is incredibly centralized and is generally in the hands of top managers or leaders. When the decision-making is left to the leaders at the top, Project Managers are unnecessarily burdened. The essential things are taken care of at the portfolio level, and the decided features are incorporated at the program level. Then the team is asked to build and test accordingly. This model will tempt large corporations or organizations because of the mindset that people at the top have more knowledge about what needs to do and how to do it than the people who have to do the work. This demotivates the team members and disengages them. However, this thought process is directly opposite to the Agile ideas and contradicts the principles used in modern management. In the present scenario, companies are better served by pushing responsibility and authority down the line. Unfortunately, SAFe® is not conducive to that. So, the team members feel that SAFe® does not offer anything different from what they have been doing or experiencing earlier. They lack the initiative and are reduced to order takers only.
The meaning of Agility is to be Agile. And that is the actual objective of Agile. In Agile, teams have the freedom to design a product, build and test it, learn from it, and iterate. Primary attention is paid to the results. When teams have Agility, they have the flexibility to change priorities or features for better results. Teams are allowed to experiment and then learn from them and use those learnings to make the required changes or modifications on the go. The planning and processes that SAFe® foists on the teams contradict this. In theory, cross-functional teams of SAFe® are called define, build, and test teams. However, in practice, the 'define' part is vested in the Product Owner. The teams are made up of only Developers and Testers. So, these are not cross-functional teams in the true sense.
One of the essential SAFe® Agile issues is that SAFe® does not provide anything to test whether an organization needs to scale or not. Most large organizations think that since they are large, they should look different, standardize things, and adopt SAFe® irrespective of whether they need to scale or not. There are already teams in place in an organization, and they are doing their work. They can do more work, so they do not need SAFe®. And most of the remaining work can be done by the feature team, which again doesn't need SAFe®. So, it is flawed to think that just because you are a large organization, you should adopt SAFe® or need SAFe®.
A team that is given autonomy works better than a team that doesn't have autonomy. SAFe® takes away the team's autonomy rather than providing it because features are provided to the team, and it is asked to work around those features. Three months' features are determined in some cases and the team ties to it instead of the results. In SAFe®, teams are bound by release trains, are not allowed to experiment and release independently, and are somewhat dependent on each other. This means that the work distributes across the different teams, and there is a need for coordination. This further weakens teams' autonomy and causes delays in decision-making. This is so because if the teams worked independently, they could have taken certain decisions independently, but in SAFe®, they have to wait for collective decisions.
The word 'epic' is often misunderstood in the context of SAFe®. For Agile methods, 'epic' means a long-term project. But it is not so in SAFe®. In SAFe®, epics are defined as considerable enterprise initiatives for which an assessment is carried out about what returns they can bring on investment before starting them. This difference in definition can lead to confusion among the team members. So, the SAFe® says, "evaluate before initiating." And once the evaluation is carried out, it is time to prioritize different projects based on the potential returns they would bring. And that is another problem in SAFe®. Because it will be challenging to bring unanimity on which projects should be initiated first, so, it's confusion again.
And this is one of the most common problems with SAFe®. So, instead of addressing the actual issues, SAFe® offers heavy processes and prescriptions which cover the real problems. It indicates more planning and meetings to resolve issues, which means more time and effort. And further, with so much planning, the team coordination work increases. In organizations where co-dependencies of teams can not be removed, they only have to work with that. But it could be reduced considerably if co-dependencies among the teams could be removed. But SAFe® glosses it over with more meetings and coordination. It does not work toward reducing the complexity of the product or team structure.
We have now seen what organizations face common problems with SAFe®. The success of any project depends heavily on the level of communication people have in an organization. And SAFe®, instead of promoting better communication, adds multiple layers in the hierarchy. And this complicates things rather than simplifying them.