Confession: I Hate SAFe Agile
I’ve only worked in a SAFe Agile environment so I cannot speak for other mumbo-jumbo forms of Agile, but I see little practical benefits from a developer’s perspective. The benefits touted from SAFe Agile are that it speeds up development times 10x and is able to create a more effective end-product because the customer is involved along the way, defining what values they want added to the product and their relative priority, all while keeping developers happier than they have ever been before. Seems too good to be true doesn’t it? That’s because it is.
The issue with Agile is that any critique of Agile is always met by the dreaded and overplayed “You’re not doing it right”. If the complaint is so common, at a certain point you have to look back and wholly assess who is doing it right and what the percentage of companies “doing it right” is. It has morphed into a pseudo-religion where snake oil evangelists have made many, many thousands of dollars teaching classes and consulting on the topics spreading their poison across various industries.
Senior management, of course, loves Agile when they can dictate the terms of its implementation. Never before have they had so many different metrics at their disposal, never mind that 90% are made-up fluff and are not being measured correctly. Stand ups, meant to empower teams, are for the most part dreaded by developers. Scrum masters and product owners, often converted personnel from middle management as they realize their former PM roles would be phased out, get to run daily grill sessions on the developers. During these stand ups, you are likely being judged on your progress and the meetings turn from developer-run to daily management-run meetings. Fifteen minute stand ups? That goes out the window as the questions never stop on your work. Never mind that I’m working on the same code I worked on yesterday, I need to give a better response than that to look like a more productive member to management. Sometimes non-technical management will be making critical decisions on feature development and timelines, forcing them on the development team without an understanding of what reasonable progress is. The development team can in turn question these estimates, however, in SAFe Agile your work is based around deadlines. Seems counter-intuitive to doesn’t it?
Agile has become a monkey’s game. How do you counteract management who wants to use Agilefall? You overestimate your work to cover yourself and your team’s metrics, you come up with 5+ different things you did yesterday even if one of those comprised 99% of your day yesterday and will again today, you create routine blockers or delays that are halting your constant feature churn. You dramatically exclaim each task in a story will take 5x what it might take just to be safe. Remember, there’s never a laid back period with Agile because every couple weeks you’re sprinting another lap. You got to build the breathers in yourself.
One issue with Agile is that instead of acknowledging pitfalls with the framework, it frees up management to take the base framework, prove that it’s not working, and use it to up their influence on the projects. If deadlines continue to fall behind in Agile? It couldn’t simply because the deadlines imposed are unrealistic or teams are critically understaffed. No. It must be because management isn’t collecting more metrics about how many stories you’re submitting or your/your team’s velocity. If only they had that insight then the project could get back on schedule. The metric monitoring isn’t improving deadline estimation? Time to ramp it up and start asking more questions to each dev during standup so I can precisely know where they’re at. If I sense they’ve fallen behind their personal arbitrary deadlines, stand ups are the perfect place to grill them and let them know I’m scouring the Jira board daily to see if they are slacking. Because there’s a couple layers between the management levels embracing these monitoring decisions and the PMs bringing these decisions to teams, all the team knows is that they better play ball and not point out that the updated decisions are anti-Agile. Did you not get your story done because the scope of the story was much broader than initially anticipated? Does not matter, all that matters is that when your team’s metrics are reported up the chain the stories that didn’t make it in this sprint/release better have a good explanation. Agile enables all this because it’s flexible and meant to fit to your (management’s) whim.
At an organization/enterprise level, it’s most likely infeasible to leave developer’s to themselves and expect to create profitable end-products. Developers tend to tinker too long on quality or certain features, and oftentimes don’t want to deal with the realization that time to market is king. The whole point of stand ups is to have developers in daily communication since left to their own devices, they might lack this communication and make costly assumptions about their work. I don’t see these as valid reasons to accept Agile and all its flaws compared to Waterfall. Developers aligned with business goals and prioritization who are able to see the whole picture to add business impact will reduce these developmental delays. The key is business transparency with developers not managerial cattle-driving.
What’s a better alternative to Agile? The sad thing is that I don’t know but I don’t see that as a reason to bull-rush ahead with Agile if it produces so much unhappiness. Developers are burning out at an unprecedented rate. If Agile is meant for empowering developers, why aren’t project/program/product/engineering managers burning out at the same rate or more than developers in this environment? Agile has turned developers into feature factory floor workers, expected to be jack-of-all-trades and masters of all. The proper implementation of Agile actually would enable a relatively happy environment for developers. Unfortunately, Agile cannot fix a broken culture or poor management. Agile very quickly exposes these problems and if not properly addressed early on, will suck an organization dry of talent and morale. Many orgs never will address these flaws and carry on with all the looming gaps in their understanding of the benefits of Agile.
For any organization looking to recover from a broken Agile culture or implementing it for the first time, I propose starting at a high-level of textbook Agile (not SAFe Agile even if dealing with a large organization) based upon the Agile Manifesto. From there, developers can decide what they think adds or subtracts benefit. Some meetings may be cancelled as the developers discover they’re a waste of time. The team may decide they all only want and need to meet once a week for 15 minutes. This is Agile at its finest.
The next step is to hire Agile consultants if you need to to tell management about their newly defined roles which is oftentimes the issue with Agile. It’s hard going from a traditional Waterfall environment where management is used to running the show and treating developers as resources to the realization that developers are now the diva kings they’ve always wanted to be. A lesser known fact, especially in traditional Waterfall companies, is that it’s very common for developers to make much more money than management and be making critical product design decisions, especially at lower levels. This radical shift started with tech companies run by former developers who realized that top developers were much harder to replace than PjMs/TPMs/ProdMs. Is it easier for any Joe off the street to take care of management responsibilities or develop the hard-coding and system design skills? It’s not that management doesn’t add value, but that it’s much easier to replace many management roles. Look at SpaceX, they hardly have any management and they’ve dramatically improved the development rate over traditional aerospace due to cutting out the bureaucracy.
My complaints about Agile management are not so much complaints about personnel within different layers of management as much as it is about the power dynamics some companies have between their engineers and different layers of managers and how that plays out in an Agile environment. Developers are the workhorses and success behind any product but individuals should ultimately choose the field that allows them to be the most successful. For some, that’s development and for others, that might be PjM, ProdM, ProgramM, EngM, etc. All these roles can co-exist within Agile as long as there’s a fair adjustment about the value proposition of each position.
I have so many complaints about Agile, specifically SAFe, that I could easily beat my estimate for pumping out a novel on the topic. I tried to give a broad overview of common themes I’ve seen in 3 different SAFe Agile environments I’ve been in, and have tried to stay informed about how other companies handle project management. While I don’t think there’s a one size fits all solution, I want to evangelize for the acknowledgement that Agile isn’t always the Holy Grail.
