The SAFe Delusion
safedelusion.com
safedelusion.com
It was a total disaster.
The idea of Agile is for each team to be responsible to improve their processes. Because improvement loops involving higher management are taking forever to complete and because each team has its own needs. "Agile" (quotes intentional) as practiced today is bad enough -- teams are not really improving their process, only implementing something taken from a book.
SAFe is taking it one step further by absolutely obliterating team's ability to influence the process.
At least with "standard Agile" it was possible for some teams to do the right thing, as long as they had a manager that understood what Agile really is.
With SAFe that was gone.
I was told that we can't even modify our t-shirt sizing because "It has to be standardised, otherwise there would be too much chaos. BTW, we are definitely not creating a new request form to change t-shirt sizes in Jira"
Forget about changing any other part of the project. We had a bunch of testers and business analysts which did absolutely nothing but had to stay on the team because they were required in the process by higher management. We did not need them. I spent time hiring people who could do the work from discussing requirements with the business people through design, implementation up to deploying it to prod, but that did not matter.
Talk about crazy projects...
It's true that such differences make it unreasonably difficult to understand or manage things at the abstraction level of the middle manager or architect's portfolio. But it misses the question of how and whether things should be managed from that level at all. Often you have someone stepping into a working bottoms-up emergent order (like the internet, or a market economy) hamfistedly trying to implement top-down central planning control. SAFe is a tool of choice for these attempts.
The radicalism of "true agile" is not about the duration of the planning cycle, but about the level of autonomy and control vested way down in the leaves of an org chart.
The issue with the place I worked and described was the director tried to build systems to "ensure" everything was organised. He could not conceive this could actually be bad. That his job was actually to focus on building environment, making sure lower levels have everything they need to be able to build more efficient systems at small scale.
He was a low level manager promoted too fast and missed the fact that his job changed.
To focus on building the environment, there are broadly two situations that can happen. 1. your director has broadly speaking total support from his leadership, and the leadership will be "patient" and trust the director to do things. 2. there is no such support, you better deliver on your KPI or you're next.
In most cases, it is in between 1 and 2 of course. If it is not mostly 1., there the director will not be able to do much without understanding the delivery. If your director needs to "push back" to help foster a good environment, they will need some ammunitions, which will likely require commitments (in time, KPI, etc.).
To be honest, it is really hard. I myself recently became director, taking over teams that were self-organized but had high attrition. "Do I enforce too much / not enough process" is a question I ask myself very regularly.
* “A foolish consistency is the hobgoblin of little minds, adored by little statesmen..." — Emerson
SAFe seems to sort of be a micro-waterfall approach inspired by Conway's law [1]. It build massive communication and coordination teams so that this gets reflected into short-term development waterfalls that produce software that mirrors the system that managed it. But this team needs to be dwarfed by the development effort they are trying to push forward or they'll end up dominating all of the activities with largely useless communication and coordination activities resulting in very slow forward software movement, confused goals and priorities, and overstaffing of projects.
Example: I once ran a team that was developing some internal tools for a large org, but we were outside of the main SAFe effort. At one point we became dependent on some service the SAFe effort was going to produce. It took 60 people 3 years to not produce a correctly working service. Exhausted with this, I finally just had 1 person build the service we needed as a stopgap. She spent 3 months building it with part-time support from one other engineer for a couple weeks. More than 3 years later that is the service that's still running and the SAFe effort never did manage to get a properly working solution out the door. I can think of half a dozen similar examples where the parallel effort by a smaller team with less organizational overhead radically outperformed the giant SAFe team -- and they did it mostly by just ad hoc communication channels between the small teams.
I am not commenting on how effective it was for them of course. It seemed to me to be a bit overkill for the size of the company I was in (about 5k people).
But only if that while is long.
It worked pretty well. A few weeks of F2F with business folks built up some rapport if nothing else.
A couple of times a year, commercial, product and tech folks would run sort of iterative challenge/ opportunity/ response/ scoping exercises within their product area, then run a couple cross-area starting with most adjacent and ending at whole business. There’d be a roadshow cycle in major locations and online for all staff.
A big investment of time, but a lot of the priority and coordination issues, as well as unexploded bombs would come out of the woodwork.
For me it was interesting to see how this kind of regular big investment in time meant that the whole org ran very lean and very client- and market-responsive.
Using 60 people to produce something 1 person could do, is like cutting this person's brain in 60 parts and connecting them with 1Hz data links.
V. Lextrait (CTO of Amadeus at the time if I recall properly) had a rule of only splitting a piece of work between multiple developpers if it couldn't fit in the otherwise single developper's head.
Otoh, searching for a criminal in the woods is embarrassingly parallelizable and would benefit from a 60 search party (forget dogs in this imperfect analogy).
Most software dev like the spoon is not super parallelizable. But probably more amenable to a single person working on each project than developers think.
My team just finished a "Release Train" where we supposably adding in a massive feature from a legacy app that required a full team of developers. The team could have probably been half the size and we could have most likely finished it in half the time, what slowed down our velocity so much was all the bureaucracy that SAFe created around doing the most simple piece of work.
The company says that need SAFe to properly track the work that is happening, but they place such a massive reporting burden on the people doing the actual work that things crawl at a snails pace. I once had to push a bug fix for which I had to create a JIRA story. I spent 20 minutes creating the story and attaching all the correct labels, 5 minutes implementing the fix and opening a PR, and then another 15 minutes fighting the time tracker to log the 5 minutes that I worked on the story.
Instead of working together with developers to solve a problem we now have to use these rigid structures, release trains, system teams, and sync meetings, to do our work. If I want to approach a developer in a different team I'm supposed to go through two scrum masters, and setup multiple meetings with clueless people, this is madness.
Instead of using decades of professional developer experience to make strategic decisions we now get these complex decision processes such as WSJF, designed by a group of MBAs. It only seems to complicate things.
And we have an army of clueless but very expensive people (scrum masters and "release train engineers" with minimal experience) who have been brainwashed to think that despite minimal training and experience they have some SAFe gospel to spread, they are the one source of wisdom, and developers are just a nuisance standing in their way.
That's exactly what it is. And that applies to many methodologies and management practices. In our company there are whole layers of management that are totally useless and unnecessary.
Took a salary cut for another job.
Haven't regretted the choice for a second: life's too short to waste one's talent in service to a bad employer.
I am constantly amazed that any working software comes out of such a process, but against all odds it does.
Executives would rather give money to the people who promised that they could get the more-valuable software without giving up any of their power and control.
I understand this can depend on how well it's implemented, but in my experience I've never seen anything like it before or since.
This is the part I don't understand. What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months?
That isn't "throwing things to the wall" or "mindlessly running around", that's trusting a team of professionals to make effective creative decisions.
There is however the argument of whether companies should look ahead for more than three months. And brilliant and trustable professionals don’t change my assessment that they should.
Success is far more likely if you decide on a goal, and then build feedback loops that let you learn. And in the internet age a feedback loop of a month is painfully slow, never mind three.
The company I work for hasn’t changed a single procedure or milestone. Neither have my clients. I am also not talking about predicting the world, but of predicting an internal kitchen.
This is just n = 1 but I’ve never seen a company that does it’s strategic planning in detached 2 week sprints.
If anything, if any sort of coherence exists I’d say that the previous sprint, the current sprint and the next sprint should have an understandable connection, and then we are already talking about a month and a half.
> I wager every company in the world was affected by the world wide changes right now.
Affected? Perhaps. Derailed? Not so much.
> Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
Both have their advantages and disadvantages, but I’d trust and would like to work, more, for a company that doesn’t flap in the wind.
No one in the industry expects stability like in the waterfall days, but to expect a company to change / adapt their strategy in less than a financial quarter is just marketingspeak in my opinion.
What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a trend or adjust for changing external conditions, I understand. But for software development?!
At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.
Different code bases in the org might even have different process certifications they have to follow, eg in medical software or some other industries. In those cases it’s downright impossible/illegal to give every team access to every repo.
SAFe is supposed to solve this. I haven’t heard anything good come out of it though so far, so I find this thread very interesting.
This requires teams to have slack/contingency time in their plans. That’s important.
Of course, there will always be situations where you don’t spot a dependency until you start coding. But in the loosely-coupled mode, that is what happens every time you have a dependency on someone else, ie you have no opportunity to spot in advance. Worth some planning exercise you get an opportunity to spot the dependency and deal with it gracefully, even if you don’t catch 100%.
But yeah, if there is no benefit to spotting early because the other team doesn’t have slack for the Q, then less point in planning in advance.
On the estimation side of things, I've worked with teams that do estimates in concrete hours, days, weeks, etc, and teams that work in abstract feature points, bushels, etc. The number one factor for whether the estimates are successful is the time spent before providing the estimate to figure out what the actual scope of the task is. If you've planned and estimated a task and didn't discover the cross-team dependency during that planning, you've failed at planning. It happens. It sucks. It should be very rare.
I've worked with teams where "sprint planning" every two weeks/whatever cadence is basically an entire engineering team getting pulled into a room for a morning, the manager/scrum-master/whatever pulls up their backlog and starts picking tasks off the top. The team is expected to provide estimate efforts on the fly in the meeting, and then expected to spend the next two weeks perfectly executing on the work they've committed to. How in the hell is a process like that going to allow people to really think through the issues that are going to arise (like needing an API change on another team, or even verifying that a 3rd-party API is compatible with what the task is trying to achieve)? These teams constantly run into the issue you've described and it absolutely sucks for everyone (the business, the managers, the developers), but the process just keeps being adhered to. Maybe in the post-mortem someone will say "we need to do a bit more analysis before doing estimates", and the outcome is that during the next sprint planning session the SM will say "HAVE YOU REALLY REALLY REALLY THOUGHT THIS THROUGH?" but... they're still doing analysis on 12 new tasks blind...
If you can get a bunch of people into a room and plan out what everyone on a software team is doing for the next three months, there's a pretty clear cap on how creative or adaptable the work can be. What is everyone doing for the rest of the quarter? "Executing"? Just filling in the "obvious" implementation details to program exactly what they're told?
Getting a clearer picture of the next 3 months should be a piece of cake. As a bonus once it’s planned you should get to focus without a sudden shift in priorities.
(Note: quickly, not suddenly. Bad performance in market validation should never come as a complete surprise. It always slowly dawns on you over the course of days/weeks.)
Another reason for changing priorities quickly is that the specification drawn by the product team happens to be technically very complex because it interacts in unforeseen ways with other functionality, and this is discovered early in implementation.
Basically, in product development, you're constantly running into things that either provide less value than expected, or cost more than expected. That's when you should do something else instead.
Once you have a great idea, yes, you should sink all of your effort and focus into that to get it to market quickly. But the idea is that if you start cautiously and change your mind early and often, you can actually implement the winners with blazing speed later without looking back.
Which is most orgs I've worked with.
I've got one foot in the pure software world and one foot in electronics hardware. I've worked with a number of startups, and some larger organizations and government.
The SaaS startup world is the exception here, not the rule. Virtually any business that is not "we're ready to pivot on a dime" SaaS should be able to plan 3 months out. Generally speaking, any kind of strategic initiative is probably going to take longer than that to roll out. If there's any kind of manufacturing involved then design, V&V, manufacturing, and QA are likely going to be running on at least 3 month cycles.
Sometimes things do pop up and it makes strategic sense to do a mid-quarter tactical shift to attack an extremely valuable lead, but that should be exceptional. Even in the SaaS world, people tend to jump on new "valuable opportunities" without really sitting back and assessing the cost of delaying everything else. This kind of organizational ADHD (one board member at a company called it "chasing butterflies") tends to result in a bunch of half-finished projects/products that all could have been valuable in their own right if they'd been run to completion instead of abandoned in favour of the next "golden opportunity".
Having worked at both very large and very small companies, people who have not worked in the other just don’t understand what it is like at the other scale.
Yep, you get this, a 13 week PLAN. Just adopting plan-old maligned waterfall can give you a plan lasting years! Unfortunately software development teams are supposed to deliver more than plans.
You can totally do quarterly planning without SAFe, cross-team colaboration can be achieved, and having teams spend time digging into future work is immensly valuable. SAFe leeches from these positives without actually enhancing them, while adding an imense amount of overhead and real costs.
Can you tell I'm not a fan?
If they have completely ignored company priorities that is bad but often it is some technical glitch has come up that moving a box 1px to the left really wasn’t as easy as first thought.
You say "for whatever reason", people feel like they are making more effective prioritization decisions in the present than they did in the past, as if there isn't a good reason, but there is: there is more information about the present in the present than there was in the past.
To me, if you aren't updating a plan in real time as information comes into view, then you're missing opportunities.
In the size of org that does SAFe, I would argue the real "unexpected" priorities that come in and require shifting significantly are few, and likely regulatory. And if you are in that sort of business environment then that unexpected stuff is also theoretically accounted for in the PI planning!
I agree that both real priority shift / additional information based changes and also politically and paranoia motivated changes occur, but I don't think it's as straightforward or obvious how to differentiate one from the other as you seem to be implying. I'm sure many of the clear cut priority shifts based on new information to me have been the obvious politically or fear motivated changes to other people with different context than me.
Personally, I just think a better solution is to prioritize detailed work immediately before it is done, whenever possible.
That it cuts our actual development output by half or more is not relevant. As long as we can churn out meaningless Jira tickets to describe all that we aren't really doing, management is happy.
The important work still gets done, but it's off the books. It would never survive PI planning.
I sincerely wish that was a joke. It's a 4 hour team wide meeting to review all work items are ready to be planned during PI planning, as well for us to identify dependencies and schedule meetings with those dependencies. There isn't enough time to to that during the actual planning.
Since then, I reorganized a team of ninjas away from the trains and have delivered at 3x the velocity using kanban methodology.
I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner. However, It's not entirely terrible as it provides some tools that can be address some organizational problems.
I think at best if a large organization is already doing well and is "agile" overall, SAFe won't provide a lot of value and is unlikely worth the investment. If an org is highly siloed, dysfunctional, and lacking inter-department coordination then SAFe it at least offers some tools to address those issues.
> I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner
This is the wrinkle, and in my experience the #1 factor for whether or not any particular methodology is going to work within an organization: top-level buy-in. Before I got too jaded, I worked with and helped some teams that wanted to try bottom-up agile, and it would help the team get better, but if a layer or two up in the management chain still wants e.g. fixed timeline, fixed budget, fixed scope projects, you're going to run into impedance mismatches all over the place and lose most of the benefits in the medium term.
This can also happen in the other direction. An organization I worked with adopted EOS on the business side of the company but didn't really roll it out on the engineering side, except for expecting everyone organization-wide to specify their quarterly goals. After setting those quarterly goals, the engineering teams would still get yanked around in multiple directions, being asked semi-randomly to work on things that had nothing to do with their quarterly goals and then at the end of each quarter everyone just scratched their heads and went "why didn't we accomplish what we wanted to accomplish?"
Maybe I'm jaded, but I've gotten to the point where I don't really care which methodology is used, but rather that everyone top-to-bottom is on-board with it and actually following it. If it's Scrum, management needs to 100% buy in to the idea that they're going to get releases at a constant cadence and that those releases will contain whatever was prioritized as the highest value, with lower value features potentially missing. If it's something more conventional/waterfall-esque, management needs to be on-board with the fact that there's going to be some very costly analysis up front (that must include engineering) and that changes to that plan are expensive and will cause the schedule to slip; engineering needs to be on-board with the fact that they will be expected to deliver everything according to the schedule they built. It doesn't matter nearly as much which approach everyone wants to take, just that everyone understands the tradeoffs with that approach and that everyone's going to follow it.
While not a fan of SAFe or any agile cargo cult implementation there were a few things I liked about SAFe: Some acknowledgement of the role of planning which imho. is needed at that scale and some framework to handle architectural concerns.
Or have a look at Coplien's Scrum patterns [1] patterns that do involve "planning", and that are also supplemented by his decade old organizational pattern work outside of just Scrum.
[0] https://www.holacracy.org/constitution/5
[1] http://scrumbook.org/ and https://sites.google.com/a/scrumplop.org/published-patterns/...
If you can do that, you can do agile. It doesn't matter if your customers are internal or external - internal might be better, because you can work with them more regularly.
This is why most companies will abandon SAFe after a couple of years, like the case studies show. I have personally left one employer (a bank) because SAFe made the job unbearable.
Both this company and their larger competitor abandoned SAFe after a couple of years. I now categorically ignore any gigs and openings at companies using SAFe - it's a glowing red flag to me.
How would a potential customer of SAFe see it?
Right now somewhere in the world there is probably a C level exec of a large org reading a powerpoint about how transformative and agile SAFe is. They’re probably in their mid fifties and have never worked in tech before. They know agile is good, but any large IT project is risky.
What would they see if they read this? Would it mean anything to them? Or would they see a bunch names they don’t recognise, and a list of failed IT projects blaming SAFe.
https://www.forbes.com/sites/stevedenning/2019/05/23/underst...
The SAFe training is predominantly a bunch of pointless games, marketing, and baseless claims. Leaving all that aside, it's just fake agile.
SAFe puts a bunch of layers between you and the customer.
Agile is about removing layers between you and the customer.
I don’t know if it is effective to do so or not, but I do see it highlighted on job ads/recruiting landing pages.
Traditional Agile doesn't scale well above the team level (not that it's bad, it's just that benefits from its processes don't seem to be focused on that level of the organization.) Scrum of Scrums is rarely executed well and Lean and XP don't really describe practices for that echelon. (I'll have to re-read my Kanban books and see if it addresses it.)
My take on SAFe is that it rigidly adds dependencies between teams, even if such dependencies are counter-productive. But like the manager who uses the daily standup as a status meeting, it seems like it's serving the "bean counters" instead of the people doing the work.
SAFe with Scrum teams (how instructors are taught SAFe) merely adds more ceremonial meetings and sucks for everyone.
SAFe with Kanban teams trades the scrum ceremony for less frequent SAFe ceremony and is a much better experience for developers.
SAFe corporate needs to change the way they teach it to address the clearly visible issues coming from the way they currently teach it, based on the comments here.
It has its flaws, but it's not the worst approach.
I've seen two successful approaches in practice. The first is vertically integrated companies using easily-measured labor-saving techniques like ML to justify the infrastructure costs required to support those innovations. And the second is places where workers have the institutional power to advocate for investment in the tools they have to use.
It seems to me that there should be an effective strategy where we treat software as capital spending that gets appropriately depreciated, but mostly what I see is finance departments trying to micro-manage development and in the process costing their company a lot of money.
I couldn’t believe it. But then again, we were quite literally the only team that delivered a product, so naturally we were seen as a threat and our contract was cancelled.
True story.
Or people who are too dumb or lazy to try language X or approach Y (minus fads) tend to reiterate how wonderful their stale way and obsolescence are.
There are people at my work (MAANG) who say Rust is too "esoteric" and "impractical" despite the whole company and industry moving that way, but they're comfortable in just now finding Go and being religious about it, maybe 8 years late to the party that's now over because it's "worse is better" shit in the long term. I'm looking around because I think my team is doomed since it lacks coherent leadership (the lead was playing with VR and skipped their own conference), it's full of "senior" people who lack professional career development goals and are uninterested in leveling, they're fine with ignoring software craftsmanship and tech debt, and they don't interact with me with any regularity. I can't get anything done or propose any ideas because the lead looks at me like Tucker Carlson before I can finish a sentence. They don't include me on anything, so I don't know why I'm there.
What I find weird about both SCRUM and now SAFe is that pretty much every single agile expert I've read articles and blog post from dislikes it. My take away is that the agile purist, if you can call them that, are focus on delivering high quality software and user satisfaction, that's the focus, that's the goal. SCRUM and perhaps now SAFe (presumptuous acronym btw) seem to be focused on managing software deliveries in larger organisations.
As some one who studies software engineering and process management 18 years ago, I can't say that time has made me think that things have improved much over time. I am especially skeptical of processes that comes with certifications and titles. The original agile manifesto is beautiful in that it's something we can all do. There's are no training, no certification, no corporate backer. Its principles, and you can either agree or disagree, is something the team can reflect and meditate on how to best incorporate the ideas into their work.
Overall, more and more I start to think that PHK was right in his talk "Entirely Predictable Failures" in 2012[1]. It's snake oil, almost all of it.
[1] https://www.infoq.com/presentations/Predictable-Failures/ (At around 24:30 and a few minutes from there).
IMO the only real issue with SAFe is that the quality of trainers have probably become diluted. If you have a SAFe instructor without a programming background to go along with it who can understand how all of the pieces involved will affect the people and the process, you're going to end up with pure by-the-book rigid implementer...because they probably don't know any better.
I was drawn to SAFe after posting a lot of venting thoughts on my blog, that got picked up here and somebody on this forum recommended a fantastic book to me. The Principles of Product Development Flow: 2nd Generation Lean Product Development by Donald Reinertsen.
https://news.ycombinator.com/item?id=17154355
This book is not rigid, nor are the principles within it. I used those principles to very successfully run a development group, but I was failing at consistently involving the business side of the house effectively. I looked around for something more formal that was based on his work and I found SAFe. Going through the training, it's about 80% based on that book. You'll recognize all of the underlying principles.
But I took so many classes on it because I wanted to make sure I understood SAFe well enough to know the goals of it's structures so that I knew how to adapt effectively. I don't think a lot of SAFe instructors do that.
So here's what you need to know about SAFe. They flat out tell you, you are NOT trying to fit the organization into this structure. You're trying to see how the principles of this structure can benefit your organization.
If you want an effectively summed up list of the keys of SAFe from everything I've learned it's this:
1. Continuous Delivery & Deployment are the primary goals of this structure. There is a huge focus on development pipeline automation and all of the efficiencies that come from it. I have no idea why anyone would think otherwise based on comments in that link, because it's absolutely core to the entire process.
2. Prioritization without emotion. SAFe prescribes a formula based approach to prioritization that is essentially a dressed up Return on Investment formula called Weighted Shorted Job First. It recommends structures to get a lot of representatives from the business side of the house to go through and apply relative weights to 3 different factors to establish a Value metric called Cost of Delay and then counts on the technical side of the house to estimate the workload. This helps you prioritize in a way that factors in Opportunity Cost. You have X amount of developer time, if you spend it on this you can't spend it on that.
This process is FANTASTIC for everyone involved except the person at the company who is used to getting things prioritized by yelling the loudest. On the business side, everybody has a clear place to have a voice in the company priorities. On the dev side, you never get the "everything is top priority" answer that is so common.
3. Feature Flags. This is one of the absolute keys from a best practices perspective and it also critical for a continuous delivery environment. It allows dev to deploy to production behind a flag rather than hold stale branches while waiting for marketing, product, etc to give feedback, documentation etc. Product gets the benefit of being able to show features to specific clients, gather feedback, etc in a production environment while everyone else can prepare to release when they are ready...without having to bog down development with that entire process. The idea of separating Deployment from Release is hard for a lot of people to wrap their heads around.
The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall.
It's neither of these things. It's made to be adapted to your company and all it involves is a collection of best practices that work really effectively together. They adopted a lot of current practices, like Scrum, into Reinertsen's work because it's easier for an organization to adopt it if they think they're already doing a lot of it. Each team within a SAFe environment can use Lean, Scrum, Kanban, etc. It's up to the TEAM entirely. Scrum structures are just there because a lot of people are already using them.
As for the waterfall bit, I reject this entirely. There's a large group of people out there that seem to think even acknowledging a dependency means you have a waterfall process and I bristle every time I hear it. The PI Planning structure allows you to coordinate team planning over 8-12 weeks.
Have you ever been in a scrum environment where the teams didn't have a clear path to coordinating? It's awful.
Moreover, the structure allows (and insists) that your developers actually provide the plan. This means nobody else has handed you a deadline and your entire team gets to have a dialog about what can be done in what amount of time. You discuss tradeoffs with management if they ask for the world and they only really need a piece and then discuss how to get that piece.
How many environments leave developers out of this process entirely? Just handing you tasks?
I'm a huge fan of SAFe because it's goal is to provide an environment where developers can thrive. Every time I see comments about SAFe and ask questions about it, I get responses like "they didn't do that in our SAFe implementation."
That's because your upper management nixed it. It's not because it wasn't supposed to be there.
Personally, I'm a huge SAFe with Kanban advocate.
If you have questions about SAFe at your company or you simply want a second opinion on what you're being told, feel free to hit me up. I'll be happy to answer any questions that I can.
The thing is, you can’t take a set of principles (which his stuff is) and then claim that rolling out your design (a different beast entirely) means that the poor customer is following them too. Ok you can try, but it wouldn’t be true.
FWIW I’m the author of one of the better-known Kanban books. Plenty of Don’s influence in that world too (a good thing), not that I’m active there now
* It starts by stating "I'm a SAFe consultant now, but at heart I'm a developer just like you!",
* It conflates what SAFE says it does (continuous deployment; empower developers; responsive teams) with what it PRESCRIBES (coordinated release trains; process over people; commitment to long term deliverables up front),
* It speaks to the executives and management that will decide to adopt SAFe, not the developers who will need to somehow work within it,
* It somehow promises to combine bottom-up agile with top-down date-based delivery commitments then hand-waves away the collision of these intractable approaches,
* It pleads that SAFe is not heavy weight even though all SAFe offers is hundreds of pages of process and rituals,
* It attacks anyone who is concerned or unwilling to do SAFe, as obviously they'r the ones with a vested interest in not adopting SAFe,
* It presents the straw-man argument that the alternative to SAFe is teams that can't coordinate,
* It concludes that if you didn't see all the supposed benefits from SAFe, "you did it wrong",
* Like SAFe itself,it's long, full of platitudes, self-promotional and in the end leaves you ready to surrender just to make it stop.
Question for the group: Do you know anyone who's livelihood doesn't directly depend on adopting or enforcing SAFe who is a big booster?
My favorite SAFe quote:
"SAFe uses agile like a drunk uses a lamp-post: for support, not illumination".
As is common with political initiatives. First the values are listed, then the motivation for those values are presented in a way that nobody can disagree with. Then the slight of hand: the proposed solution is assumed to be the only possible fulfillment of the values. All discussion about the mechanisms by which the solution fulfills the promises of the values is cast as disagreement about the values. "How could you disagree with coordinating your work" instead of "how do you think our activities don't lead to coordination between teams".
It's unfortunately a very effective strategy.
> It somehow promises to combine bottom-up agile with top-down date-based delivery commitments then hand-waves away the collision of these intractable approaches,
It OK to fail few early goals or dead-lines until right pace will be found.
Product owners are not the customer. Scrum is watered down agile.
SAFe is simply not agile.
I’ve also never certified anyone in SAFe professionally. The principles work but I’m not a believer in adopting it strictly in organizations. Instead I observe and recommend improvements in existing companies once I understand their dynamics.
In many cases, aspects of SAFe are effective recommendations.
Whether you formally follow the PI Planning approach to get everybody together or you find a better fit for remote staff, letting your devs plan 10 weeks at a time instead of 2 is beneficial for everybody. And cuts down on a lot of every 2 week meetings to support it.
And all I’ve shared is my own experience. I constantly see straw men arguments against it posted.
When you scrap the SAFe with Scrum approach and replace it with SAFe with Kanban 90% of the ceremonial meetings go away.
Most devs I talk to don’t even realize there’s supposed to be a backlog that they prioritize without having to consult the business side of the house.
There’s no question that the anti-SAFe crowd has legitimate gripes with bad environments. Their concerns aren’t any more valid than the concerns of anti-Scrum proponents who have been in bad environments.
It’s trying to solve a hard problem but under the hood it’s just best practice after best practice smooshed together.
Get the scrum ceremony out and SAFe gets a lot cleaner for everyone involved. You’re basically just adding more ceremony if you use scrum within SAFe. If you use Kanban, you trade for much less frequent ceremony so you can focus.
SAFe instructors are taught WITH the scrum ceremony and IMO that is the root of all of the blowback.
Three years down the line, every customer is using a slightly different combination within the hundred flags that have appeared, you’ve just fallen back the latest release for the fifth time because of an unforeseen interaction between three unrelated flag states, and then you go through the test suites and you realize that it is mathematically impossible for you to cover every combination :)
Feature flags are controlled entirely by the product team and designed to be removed after the product team has formally released the feature everywhere. Good feature flag systems like Unleash even track stale flags so you don't forget to remove them.
It is incredibly rigid though.
Very few people on my team files defects; in fact in the last year we've probably had 4 maybe opened internally. This is in spite of the fact that there's constant complaints and identified problems and risks that we keep finding.
The problem is that in filing a defect, we must go through the entire ceremony. The PO and SM must evaluate and prioritize, then gather the team so that more details can be filled, a Definition of Done written, acceptance criteria written, and the time estimates voted on. Along with the the fact that the defect requires two reviewers to read over and approve merges, and then an additional two reviewers to read over and approve the defect.
It's more time and cost effective for us on the team to wait until either someone else finds it, or until it actually explodes, rather then going through the rituals of preventing the problem in the first place because we strictly follow good SAFe practices.
During PI planning is when it really comes to a head; often times stories have to be tortured into either fitting into our mandates that no stories can be over estimated over 3 points. The mandates been a mixed bag; in some cases it sensible splits the feature into an investigative phase and an implementation phase. But other times we have to torture the story to the point where the split is meaningless or even detrimental to the delivery of the feature.
Just a rough example; if we split the time boxed investigation, the implementation story is in the next sprint kept at the same story points even if it turns out we've drastically underestimated the work. It also perverse incentivizes just voting 3 points even if it's a slightly more complicated work because the team often doesn't want to deal with the headache of writing more stories, and pressure during PI planning to get it done.
>Have you ever been in a scrum environment where the teams didn't have a clear path to coordinating? It's awful.
It's still pretty bad. PI planning for us is 2 weeks of planning for a 12 week PI. 8 hour days of nothing but sitting in a virtual meeting room staring at someone write up stories and then voting on them (to be fair we've gotten it down to 2 weeks now by running some of the ART planning in parallel). And these stories are not easy to write; the current standing directive is that they need to be detailed enough so that anyone off the street, irregardless of level of skill or familiarity, can read the story and bring it to completion (which has led to some disagreements on how long it should take to write a story). Then voting on story points which in theory are supposed to be complexity but in reality are treated as 1 story point = 1x 8 man hours.
The two week sprints in the PI starts with a 3 hour review meeting. During this time we also have to come up with sprint goals, often times an exercise that ends up with our SM instructing that he didn't care what goals were (which has about the effect one would expect; meaningless goals).
Then we have another 3 hours planning where the PO reads off a chart that could've have sent prior to the customer as an email with an executive summary, followed by time spent by the SM calling out stories and then asking for volunteers. And then voluntelling if no one does.
Each day is then set with a 15 minute scrum and then an additional hour standing review / second daily check in. So every day is at minimum 75 minutes of meetings per day. And the SAFe process really does encourage mediocrity if not idiocy (one of the biggest pushes for return to the office I've heard in fact is because SAFe requires face to face meetings. This was said by certified SAFe Professionals).
>I'm a huge fan of SAFe because it's goal is to provide an environment where developers can thrive. Every time I see comments about SAFe and ask questions about it, I get responses like "they didn't do that in our SAFe implementation."
I went through SAFe training. We have something around 15 or so certified SAFe Professionals. One of the things that really stuck with was this ridiculous sentence; that we have teams build ownership by letting them pick their own team name. Not by letting them decide architecture. Or somehow figuring out how to build trust between the SM/PO and the team. By letting them pick. A team name. And this was stated straight faced and completely seriously by a certified SAFe Professional with two other certified SAFe Professionals.
Kind of gives you a hint of how we've implemented SAFe. All of the rituals followed, all of the ceremonies performed, but done in an air distrust between management and engineers. It's not that it's all bad; there's many pieces that makes sense but many more that don't and if the foundation is on the view from management that engineering is little different then factory work..... well, just look around this thread. I think you can see the result.
This helps paint a lot of things in retrospect a lot more clearly. As you can see, I am still intensely salty about this experience many years later. >:')
> we strictly follow good SAFe practices.
and
> PI planning for us is 2 weeks of planning for a 12 week PI
This is a hellhole that in no way reflects good SAFe practices. PI Planning is 2 days. 2.5 if you're partially time shifted to accommodate teams in disparate time zones.
There's so much more about this that I want to respond to but I'm going to shorten it to this: SAFe calls for planning a maximum of 2/3 of your estimated capacity (based on historic velocity) and then leaving the last 2 weeks of the PI entirely unplanned. All of this is built in buffer time specifically to ensure time built in to deal with unexpected things that will inevitably come up. Defects in production should be addressed immediately in any environment.
Any label put on the process your describing is probably not fair, whether somebody called it SAFe or Scrum or Kanban or Lean or Extreme Programming or whatever else.
This is simply a terrible and broken environment facilitated by people who apparently had no idea what they were doing. This is an environment where managers have exerted strict control rather than allowing people close to the problem to take the action that they know needs to be taken. Which is again...not SAFe.
Our PI planning consists of a combined demo session and Q&A, a combined I&A, then separate demos and I&A's for each of the ART's. That in of itself can take 1 to 2 days because of the number of demos that each ART has to include. Then 3 or 4 days of team breakouts for writing stories, a full day for draft plan review, then another 2 to 3 days ish days to take in feedback from the review and adjust the plans, then another day of final draft plans review.
You can't fit that into two days. You can't even fit that into a week. But those those rituals are more core to SAFe Agile then an arbitrary time frame for PI Planning. So the 2 day limit had to be dropped to fit in the core principles of SAFe.
So yes it does align and yes it follows good SAFe Practices. Didn't you yourself say that one shouldn't try to the organization into SAFe's structure?
> There's so much more about this that I want to respond to but I'm going to shorten it to this: SAFe calls for planning a maximum of 2/3 of your estimated capacity (based on historic velocity) and then leaving the last 2 weeks of the PI entirely unplanned. All of this is built in buffer time specifically to ensure time built in to deal with unexpected things that will inevitably come up. Defects in production should be addressed immediately in any environment.
Our sprints are loaded to 50% to 65%, with few exceptions. But with how big our team is, that means that 2/3 loading is around 40 points per sprint that needs to be planned. And our standard practice also are expected to pull in New Features / stories from the next sprint, or work on items as assigned by the PO from the backlog if things are finished on schedule.
>This is simply a terrible and broken environment facilitated by people who apparently had no idea what they were doing. This is an environment where managers have exerted strict control rather than allowing people close to the problem to take the action that they know needs to be taken. Which is again...not SAFe.
All our Certified SAFe Professionals says this is SAFe. The training I got aligns to what we practice. This is SAFe by the strictest definition of following processes and practices.
But like Russian elections and referendums, you can have all the form, technically meet all the criteria, and have none of the of substance. And be honest... would it surprise you one bit to think that insincere ceremony isn't exactly what many so called leaders want?
It allowed the 3 teams to have better communication, things were written, we knew what we are building and how/who is using it. Met with stakeholders regularly for feedback and better understanding of the business in general, the strategy and why we need to land this feature either to differentiate or because it is priority 0 asked by many customers.
As a team member safe allowed me to understand why what I am working on is important for the business and how it brings value.
I wonder if it is a people problem that we are blaming safe for or an actual process problem?
It sounds like most of what you listed is something that could be accomplished with a good scrum team that has a well-defined, prioritized, and pruned backlog (as necessary.... :))
SAFe prescribes a bunch of structures, councils and processes. It is by design anti agile.
Edit: this image highlights the paradox: https://www.agilest.org/wp-content/uploads/2018/03/scaled-ag...
Just try to count all the roles and processes prescribed.
The meaningless terms, the disconnected-flow-chart-but-not-a-flow-chart, the deluge of acronyms, the weird visuals and the inscrutable words and relationships, it's all there.
It's a document I'd attempt to create if I was trying to parody consultants and business shenanigans, but it's real.
SAFe is a key component of an "agile transformation" which is a bit like the "peace process" between Israel and Palestine: the participants who implement the process are best served if no progress is made while they project the illusion that progress is being made.
Otherwise I don't miss anything about it.
It was an unmitigated disaster, everyone was miserable. Developers were leaving so quickly consultants were brought in to stem the bleed.
When I left the CTO was trying to retain the little talent there was left by holding monthly Q&A sessions. The final question I heard before I left was something like, “why are the consultants treated better than the employees? They don’t have to do SAFe.”
It’s like a diet that promises you can eat as much of whatever you want, as long as you pay.
This analogy never fails me. SAFe brings tools and benefits on that level. For everyone below, it is waterfall pain.
And let's be honest, SAFe is not for "I can attract talented people who can self-manage" companies. It's for "75% of my developers are scraping the bottom of the barrel, but I take what I can get because my company isn't sexy."
This is true of all Agile methodologies adopted by corporations.
If it weren't true, the methodology would not be adopted.
Yes. Not doing SAFe.
(I am a frustrated Christian)