Scaled Agile does not cure the lack of engineering maturity – Enterprise Irregulars

Scaled Agile has the status of a religion in many tech shops I know. Like with religions – its followers express unquestioned faith, intolerance for other ideas (Waterfall is the devil, EVERYONE should be trained in SAFe), and its praises will drown its criticisms (its not a problem of the framework – you are just too dumb to use it right) , and a whole branch of philosophical discourse seems to have developed around it ( its a way of life, its a culture, Its a journey and not a destination….) , and people who won’t know a CI/CD pipeline if it slapped them across their face have turned into its evangelists.

To be fair – it does work quite well at several software development companies. And on paper, I think it says all the right things. Actually the main diagram on the website is quite comprehensive and thoughtful and I like it. I go back to it when I have to debate my views and its quite useful to remind people on the principles .

My views here are not about the theory – they are just about how I seen it practiced. Now – the trend is “every company is a tech company”. That may or may not be true – but I can say with some conviction that the IT organizations of most of these companies that have embraced SAFe have not figured out how to do it efficiently and effectively.

Let me touch on a few things that are glaringly obvious

PI Planning.

A good part of SAFe education is about explaining how the process differs from waterfall. But if you look at how it is practiced in real life – especially if you sit through a few PI planning sessions – you most probably will walk away wondering if all that education was wasted. Lot of PI planning sessions scream classic waterfall project planning. While the intention may be to explore “WHY” , the actual sessions usually are debates of “WHAT” and “HOW” – which obviously bleed into the sprint planning and execution too. Also – while conceptually the intention is to agree on goals, in reality most of the agreement is on actions. If you are deciding upfront for next few months – are you truly in continuous discovery mode you set out to do ?

Structure and Process trumps Autonomy and Agility

Agility needs autonomy. And for a dev team to be autonomous – they need to be close to the people who actually use the product. How many engineers actually even see a real user and know first hand what outcome is best for them ? How many engineers only talk to ONLY their managers and product owners ? How many roles are needed to get SAFe to work – and are they helping or hurting agility in execution ? In practice – most of what seems to happen in the place of “product thinking” is classic project thinking, which is about tasks done within a specified time line. I think SAFe definitely helps with top down communication quite well given it is built with the traditional pyramid in mind. But is it helping back and forth communication with users ?

Deliver on cadence, Release on demand

This is the part of SAFe I personally like the most. But I very rarely see this happen that way in the wild. What does happen most of the time is that “deliver on cadence” works reasonably well – and that satisfies management because predictable rhythm helps measurements . But there is little to no ability for a lot of teams to come close to “release on demand”. Its not that teams don’t want to release on demand – but that will need fundamental re-engineering of what was done in the past. It takes time and money and specialized skills – which often don’t show up in abundance . And since rhythm of development is what gets rewarded, the “release on demand” dreams are kicked down the road .

Engineering maturity, or the lack there of

I think several companies have rushed into SAFe without investing in sound engineering practices first. So while speed might look to have increased overnight – there are a lot of holes to be poked on value generation.

If I am king for a day – I would prioritize instituting solid engineering principles over teaching agile and SAFe. Once you have a strong engineering foundation, Agile works really well. Maybe SAFe will work really well too. But if you don’t have strong engineering capabilities – all that agile does is to accelerate creation of terrible code that future generations will curse you for.

How do you collect and organize requirements ? If you do a sprint for requirements – then for dev – and finish with a sprint for QA, do you call that Agile or Waterfall ? Just asking for a friend

In the name of “engineering fun” or just pure incompetence, have you ended up with more anti-patterns than patterns in your code base and now trying to work on making it awesome with SAFe ? Are you comfortable with introducing a shift left culture given where you are ? How is your test coverage – are you certain you are not just testing the same thing ten different ways ? How well do your teams conform to frameworks or does everyone do their own thing in the name of speed ?

In the interest of speed, is Ops compromised ?

The unsung heroes in the tech world are my friends who focus on Operations. A lot of the conversation has always been about how the Dev side of DevOps works. But when the pager buzzes at 3AM – in most shops, it is usually not the developer that wakes up to log on and find what went wrong.

The lack of engineering maturity expresses itself perhaps the most strongly when apps fail. You cannot stop technology from failing – but you can and should be able to minimize the impact and make it easy for users to not be affected for too long. That cannot be an afterthought – it needs to be designed for upfront and operational sturdiness has to be a first class citizen for all development. What is the reality in how backlog gets managed – where do you find “observability” in the list ?

Where to from here ?

I started this as a rant on SAFe – but I think the solution is not about a focus on doing SAFe better. I firmly believe a “back to engineering basics” is where the most value is for most companies. Once you have a grip on that – I think the execution methodology will take care of itself for the most part.

(Cross-posted @ Vijay’s thoughts on all things big and small)