How to make the case for code quality in a SAFe environment

Question

SAFe - Scaled Agile Framework for Enterprise.

Basically take the agile approach and also have 2 week sprints making up 12 week iterations with planning events once a quarter.

Context is a company that is moving from traditional development to an Agile SAFe based approach.

What quickly emerges is "waterfalling the sprint" so that many of the problems that Agile is intended to address, particularly around quality improvements, do not happen. This is because, based on what they understand about SAFe, the business is:

• Still working off deadlines that are fixed in advance
• Treating testing as a second class decision to development
• Still favoring short-term new features over long term quality changes
• Rubber-stamping code reviews and pull requests in the interest of speed
• Not understanding how TDD and BDD work with SAFe's sprints and iterations
• Not encouraging developers to find improvements with business users still controlling
• Allowing teams to plan at 80-90% velocity of capacity leading to insufficient time for quality

Answer 1

Although I think SAFe is not Agile at all, it just brings new words for the same roles, processes, and probably no change, like you're describing.

But SAFe does mandate Built-in Quality as one of its core values. So I am troubled you need to make a case for its practices in a SAFE environment. Sounds like it is time to talk the SAFe Lean Agile Leaders, which are also part of the core SAFe implementation. They should place some items on the implementation roadmap to make sure everyone is trained in Built-in Quality.

Rather than a frontal assault on Agile, they take an “embrace and extend” marketing strategy, so you will find every buzzword you’ve ever heard from the Agile and Lean worlds including Scrum, Kanban, XP, Lean Startup, Lean UX, Continuous Delivery, and DevOps.

But it’s just a marketing strategy. Mostly they just redefine the meaning of these terms to obscure their purposes. An Epic becomes a “mini business case;” the concept of governance sounds less onerous when called “lean governance;” and program management might cause less angst when positioned as “agile program management.” The constant talk of iterations and agile obscures the reality that these “Agile Release Trains” are mostly happening every 10 weeks.

I could go on, but hopefully you get the point. The core benefits of Agile and Lean are lost. More accurately, if you follow their process, I find it inconceivable that you’ll be able to achieve the underlying benefits of innovation that can come from effective use of Agile and Lean methods.

https://svpg.com/revenge-of-the-pmo/

I would think twice before joining a SAFe company. :) Goodluck.

Answer 2

My experience is that it is easier to sell a team on changing a process after they see that their old process doesn't yield the desired results. They may recognize that something is wrong but not recognize that the process is the problem. You might help them by collecting metrics relevant to the change you want to make. Quantifying code quality is hard, but even having noisy, imperfect metrics could be good enough to sell people on experimenting with a different process.