The Pros and Cons of the Scaled Agile Framework (SAFe) www.educata.org- What is your views?
www.educata.org

The Pros and Cons of the Scaled Agile Framework (SAFe) www.educata.org- What is your views?

If you touch software development in any way, you know all too well about today’s imperative to deliver higher quality software faster.

The reasons to meet this goal are plentiful, and teams no longer need to buy in on speeding up their processes. But knowing what you need to do is one thing. Knowing how to achieve that goal is quite another.

So how can testing and development teams bring higher quality software to market faster? Numerous approaches have emerged in recent years to help answer this question. One of the most talked about approaches today is SAFe, aka the Scaled Agile Framework. But what exactly does SAFe entail? And what are the pros and cons of using it compared to agile? Here’s what you need to know.

A Primer on SAFe

SAFe was developed in 2011 to help software development teams bring better products to market faster. Based on a combination of agile and lean principles, SAFe calls for close collaboration and alignment across teams and aims to centralize decision-making. SAFe offers multiple configuration options depending on the size of the team and includes three levels: Team, Program and Portfolio.

Ultimately, SAFe allows organizations to visualize the “big picture” by mapping roles, responsibilities and activities required for software development. In doing so, it helps organizations answer questions about a software development initiative’s alignment with business objectives or its predictability. It also helps identify how to measure success and pinpoint opportunities to improve workflows.

The impetus behind SAFe was to make agile principles scalable for large enterprises, and the framework’s ability to centralize decision-making and bring a top-down mindset to a typically bottom-up process accomplishes that goal.

Pros of Adopting SAFe

The biggest benefit of adopting SAFe is the opportunity to tap into a relatively lightweight framework that creates efficiency in software development while maintaining the centralized decision-making necessary at the enterprise level. Essentially, SAFe extends the idea of agile beyond the front lines of software development to software leaders who must answer higher level strategy questions.

Specifically, because SAFe was designed to maintain a big picture view of software development, it can easily handle a coordinated strategy for large-scale and complex projects with teams that number into the hundreds. However, because it is rooted in agile and lean principles, it remains more efficient than traditional approaches to software delivery.

SAFe is particularly beneficial for organizations that need to work across teams, as its centralization makes multi-team coordination possible. In this scenario, it allows for standardized processes across teams and helps avoid obstacles and delays that may pop up when different teams need to work together.

Another notable benefit of SAFe is its ability to help teams maintain alignment with business goals. This alignment can often get lost in agile environments that take more of a bottom-up approach, as developers and testers can sometimes lose sight of bigger picture business objectives. In contrast, SAFe’s top-down alignment and centralized decision-making helps ensure strategic objectives remain top of mind and that all decisions get made in support of those objectives.

Cons of Adopting SAFe

Although SAFe brings many benefits to the table, it also comes with its drawbacks. For instance, many teams find that SAFe takes too much of a top-down approach.

SAFe provides additional layers of oversight, administration and coordination. These layers make SAFe particularly popular with larger enterprises, but somewhat ironically they make it resemble the waterfall approach that many teams are trying to leave behind. And where methodologies like scrum give more freedom to developers to identify and solve problems that arise due to different sprint cadences, dependencies, etc., SAFe calls for administrative roles to oversee multiple projects and coordinate those releases and dependencies. In taking this freedom away from developers and harkening back to a waterfall environment, SAFe can often slow down processes and limit flexibility compared to an agile environment.

Along the same lines, the bigger picture, top-down approach of SAFe removes front-line players, including developers, testers and product owners, from the decision-making process and even from one another. This distance can limit their understanding of the entire software development lifecycle and hinder their ability to conduct well-informed and collaborative planning sessions as a result.

Finally, the fact that SAFe emphasizes the big picture can often lead to longer planning cycles and more fixed roles within development cycles — two points that go against the ideas of delivering in short sprints to get new software to market faster and creating a continuous loop to ensure quality at every step of the way.

Will You Play it SAFe?

At the end of the day, SAFe brings a lot to the table, particularly by making it possible for organizations of a certain size to take a more agile approach to software development. However, it’s clear that SAFe has several shortcomings of which teams should be aware and plan for prior to adopting the framework.

As with many methodologies, there’s no right or wrong when it comes to whether or not your organization should adopt SAFe. Rather, it’s all about educating yourself on your options as well as your organization’s unique needs so that you can determine the best approach for your team.

By Qasymphony Team

Chris Wilson

Improving Outcomes

5 年

I think you’ve missed the mark here on SAFe. First it does not centralize decision making it de-centralizes it, by moving as many decisions as possible away from management and to the people closest to the actual work. I find that too many people try to take a well defined frame work like SAFe and take only the parts they like about them and ignore the parts that actually force you to change bad behavior and thus this is why those that end up working in one of these partial implementations find issues with it.

Abhishek, your article in general is good. But I think some of your comments regarding the cons of SAFe indicate to me some bad experiences in implementing SAFe. SAFe is not for projects, organizations need to transition to organizing around value with dedicated teams. Whether it’s a large or midsize organizations, the reality is when you have a few hundred developers and testers organized around value and delivering the software, they will require more alignment, etc. organizations build complex things and SAFe actually does a great job of creating a way of working that manages that complexity. SAFe’s purpose, is not to make organizations agile or lean, it is to change the way the organizations works to enable it to achieve better business results, to that end agile, lean, DevOps, continuous integrations, etc. are incorporated into the framework. And last point, Teams are NOT the center of the world, achieving better business results are! Teams of course are critical to this and SAFe places high value on them and does not remove their autonomy, empowerment, or self-organization, but there are realities when working in concert with many other teams, suppliers and parts of an organization that require some adjustments.

Deepak K.

Agile Technology Expert | App development & Technical Product Management Specialist

5 年

Good Article, However i do not agree(just in my view) with this statement 'the bigger picture, top-down approach of SAFe removes front-line players, including developers, testers and product owners, from the decision-making process and even from one another.' This is the Reason SAFe have ART sync for PO's and SM's, this allows them all to be in Sync with the approach. Also PO has Team backlog's ownership and they do take decisions based on the Information they have to deliver product. Don't forget about the PI session, where Product Manager, Solutions Architect and executive are readily available to share any information coming from the team and helping teams make decision right away without any delays.

要查看或添加评论,请登录

Abhishek Shukla的更多文章

社区洞察

其他会员也浏览了