I wasn't aware of SAFe until one new manager got our director to loose his head for it and institute it in all teams.
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.
The middle manager brain has "consistency" as a terminal value. Being responsible for more activity than they can hope to substantively understand, they "need" systems that make it all look the same so it can be measured, summarized, compared, etc. Otherwise they get the intuitive sense that it's all chaos and mayhem and can't possibly be working well. It's the same sort of thing as an architect being mad that different services have different internal architectures, tech stacks, code styles.
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.
I think the issue is that middle management does not yet have "true" leadership ability. Rather than getting people to do what they want, they are trying to build systems to achieve the same. Too bad they don't understand you can't force people to do things. Not knowing how to actually manage at larger scale, they are trying to solve the problem the same way that worked for them at small scale and just scale it up.
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.
One issue is visibility. If things are perceived as not going as well as they should, and there is no visibility, it is extremely difficult for any leader to defend their group.
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.
This comment gets right to the root of the problem. People standing above emergent order looking down (typically) want to control it, but they'll never have the knowledge or bandwidth to control it well. So we play out Soviet economics over and over again in the corporate world.
That's a failure mode of middle management, but it's not a problem inherent to middle managers. Good middle managers know that every team has its own best ways of working, just as a good manager tailors their actions to individual reports' needs.
SAFe seems to be a bit like "internet scale", it's designed for very large organizations building very large single software solutions. Most organizations wildly overestimate their size and the size of their solutions. A Microsoft Office release probably can benefit from SAFe, an update to an auth microservice maintained part/time by a team of .75 FTE doesn't.
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've worked in a number of large orgs that have used SAFe and it always seems that you end up spending more time on the bureaucracy than actually writing any code.
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.
So you spent 40 minutes on a bug instead of whole week? Why?! Just use concise and vague descriptions of your work, like "day 1: trying to reproduce the bug", "day 2: investigating root cause of the bug", "day 3: fixing the bug", "day 4: testing the fix", "day 5: performing release of the fix", and so on. They are very short and fast to type, so you will have lot of free time to do an actual work.
>It took 60 people 3 years to not produce a correctly working service. [...] She spent 3 months building it.
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.
It is worse than that. Try to get 60 people to pick up one spoon for example. The coordination overhead and arguing “which spoon”
and “we should consider picking up a knife!” means it is easier
for one person.
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.
To me, it feels like SAFe was specifically designed to insert some expensive consultants between the developers to profit off software development without doing much actual work.
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.
> To me, it feels like SAFe was specifically designed to insert some expensive consultants between the developers to profit off software development without doing much actual work.
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.
I took a SAFe training class once, and they explained that Wal-Mart does this sort of exercise quarterly. Rents out a warehouse, flies in all the dev managers and leads, and does sprint planning using all the boards they have stood up everywhere.
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).
I worked at a company that did something similar. IT was west coast and business stakeholders were east coast. Twice a year the business stakeholders would come out to present the current landscape, work out their roadmap, and maybe even focus on detailed requirements for immediate stories. At the end, the business stakeholders would all get in a room and present their roadmaps.
It worked pretty well. A few weeks of F2F with business folks built up some rapport if nothing else.
I’ve seen this work really well in a successful globally-distributed business with a few thousand employees, the majority being devs. The outcomes of building rapport between people who work intensely with each other a few weeks a year is hard to beat, except maybe by the impact of getting whole of business alignment including bigger and bigger groups inside the magic circle.
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.
Here's a 2018 GDC session about the game developer Bungie using "big room planning". Once a quarter, 300 people (40 dev teams) come together in one big room to collaboratively plan their next quarter's deliverables and sprints.
It's absolutely useless to me. I cannot possibly sit there for hours, listen to other teams drone on about things that have nothing to do with me, and be expected to retain any of it. I can barely tolerate the "smaller" weekly ones where I have to listen for my name to read my script I wrote about what I did last week, and I'm very thankful for work from home because for the super long company-wide bullshit meetings where I don't participate I can simply mute it.
I'm currently a year into a role as Lead SRE in team working in SAFe. We plan five 2 week sprints for which we immediately write off 50% of our time as "BAU activities" and the rest of our time is spent lurching from one deliverable to another in the hope we actually achieve something before we get "re-prioritised" yet another time. It's not even SRE, it's 2nd line support and platform engineering.
I really have no idea how SAFe works or how it's meant to work, but everyone seems happy so long as I complete my JIRA tickets on time because that's what the users want.
I don't know if we claim to use SAFe were I work, but this sounds very similar to my experience. It frustrates me to no end, but as a contractor I don't get a say and the full time employees seem to be okay with the status quo.
I am constantly amazed that any working software comes out of such a process, but against all odds it does.
I was originally trained as a lad in classic waterfall and was a CMM auditor at one point - I got SAFe certification a few years ago and my overwhelming impression was that they had replicated all of the flaws of these methodologies, just with the word "agile" inserted wherever possible. I suppose that it is the final representation of the principle that any revolution becomes the new orthodoxy in a generation and ends up as ritualized as what preceded it.
I thought Scrum would be more a candidate for that, when the rituals from there become useless orthodoxy. If (since) SAFe implementations are just waterfall with all its flaws rebranded, it's more the counter-revolution disguising itself.
As soon as people forgot that Agile was about organizing workers & having management trade its power for more-valuable software, it was basically doomed.
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.
At my last company we used SAFe and I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, with dependencies between teams, with wiggle room/flexibility, by the end of the event.
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.
It sounds like you had a healthy org. The problem with most other orgs is that they do the same planning, with the same care and attention paid that yours did. But then 2-4 weeks after, everything that was discussed and agreed upon and planned around is upended when "priorities changed" or "something else came up" (i.e. the wind slightly blew). For whatever reason, they feel like they are making more effective planning decisions now, by the seat of their pants, than they did when literally everyone was in the same room and putting real thought into the whole thing.
It's funny because I have the opposite criticism. What I dislike is that when people discover things that need to be done, there is all this pressure to wait months to prioritize that work. Not very "agile"! I already dislike the pressure not to work on things we didn't have a conversation about in a sprint planning meeting, and that's only a week or few. Detailed planning months ahead just doesn't click with me; it feels like guesswork and I don't like guesswork.
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.
Yes, something unexpected should change things. I'm not talking about those situations. The situations I'm describing are artificial. The only thing that changed in my scenario is people started getting antsy and playing politics to get their thing more attention than some other thing, both of which were discussed and prioritized in the very detailed all-hands I'm referring to. Or some higher-up asked about when something was going to be done and that spooked the product owner.
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 think more different kinds of organizations have started doing SAFe than you think!
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.
If something else came up is not allowed it means you need a perfect plan that survives contact with reality. This is possible for short tasks perhaps but not an entire team for 90 days.
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.
Yeah, "company priorities" is the level I like longer horizon planning to be at. "It's important that we achieve X, Y, and Z in the next quarter", with well thought out priorities and clear communication, then let teams figure out how to deliver.
Why does that sound so awefully familiar? Even worse when you throw in good old re-inventing the wheel, not revise the decisions that should be and giving Agile coacjes and scrum masters more influence over the content of what should be delivered than the actual domain experts doing the work. I'll let you guess what role I have in all of that right now...
Imagine taking a two day course and then going into the office of a law firm or a hospital and micromanaging the staff. Tragic that software engineers put up with this.
> Once a quarter, we had a 3-day event in which the entire next 3 months were planned out,
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?
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?!
You can predict some things, sure—but there's a massive leap from that to planning "the entire next 3 months"!
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?
I guarantee your product team has enough things that they want done to plan your next 3 years.
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.
Oh the product team has good ideas for the next decade. The question is how many of them have they actually had a real chance to validate with real users in production? Close to zero, in my experience. That's one reason why you want to be able to change priorities quickly.
(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.
Your team is working on a dozen features for the next three months. After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. The other team already has all their time booked with feature. Cue a cascading set of slightly changing priorities. Now multiply that by every team in the company hitting something like this.
> After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API.
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...
Dream scenario - in the planning session note you depend on an external API. Prioritize an early spike/prototype of the feature to flush out dependency risks. Discuss relative priorities with the other team & schedule the work to modify their service.
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.
It looks like risk planning was not done by your project manager. Risk planing includes risk prediction, calculation of possible time and/or monetary damage, risk reduction. For example, if we see that Foo can cause problem in near future with probability of 10% and can delay project with 5 members by 3-40 days, then average risk of lose is `0.1 * (40 - 3)/2 * 5 = 9.25` man-days. If we can reduce risk probability by factor of 10 by spending 2-man days of work early (1 man day of project manager + 1 man-day of a developer), then we will reduce cost to `0.01 * (40 - 3)/2 * 5 + 2 = 2.925` man-days, so 6.325 man-days are saved.
In my experience most companies specialize teams to various extents which makes true collective ownership difficult. An iOS team is likely going to have difficulty dealing with the ML code. This becomes even worse if the change is complex or touches the domain specific patterns.
It's known as «the bus problem». Peer review is used to address this, to make someone else a bit more familiar with your code, so he will be able to help you when you are overwhelmed and need help (or when you hit by a bus). Also, built-in documentation, run books, guides, and automated test cases are very helpful for those, who are not familiar with your code base. It reduces job security tough. (I hit by that multiple times, because, for management, it feels like good developers and good administrators are doing nothing or constantly pick-up very easy tasks to do).
But the iOS team can’t know everything about the server API, the ops team has no control over App Store release processes, iOS team usually has no push permissions for Android etc
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.
Sure! I often start to make things which seem like a good idea at the time but after 1--8 weeks of A/B testing (or other verification methods) it turns out the market was not what I thought and it would be a waste of time to pour more work into it.
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.
> 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?
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".
Three months!? Is this the stability we expect from companies in our day and age? I would think it's a lost company, one that couldn't somewhat predict what the next three months are going to look like.
Just look back 3 month and assess how many of the things that happened were predictable (keeping in mind the fact that hindsight is 20/20). I wager every company in the world was affected by the world wide changes right now. Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
Just throwing things to the wall and see what sticks is not agility, nor is it just mindlessly running after any random car like a dog chasing the mail man.
Who said anything about "mindless"? Just because work wasn't planned in detail in advance does not make it mindless—the people actually doing the work make creative, nuanced decisions as they're working. Not pushing a top-down, up-front plan gives people more room for careful nuanced thought.
That isn't "throwing things to the wall" or "mindlessly running around", that's trusting a team of professionals to make effective creative decisions.
Who said anything about detailed planning? You’re throwing this in and then using it as a lever to push an engineering led approach. There is no such argument in this thread.
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.
I agree, if you have team of experienced professionals tgat is. If not, well, stuff to the wall it is. If wrapped in sometjing something agile, at least it looks good.
Trying to guess the future of complex systems is an exercise in hubris.
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.
Is that goal for next week? Two weeks? My argument was that three months is too little for any sort of company strategy. We’re talking about a financial quarter. You don’t even have the time to measure your decisions.
I'm pretty skeptical of this kind of thing even for enterprise software. I can imagine scenarios where it's relevant - if you're planning to release Disney+ in 6 months, yeah, you'd better coordinate pretty tightly to make sure you're not missing some key dependency when you flip the switch. But I've seen multiple incredibly successful enterprise products developed through the "throwing things to the wall and see what sticks" approach.
> Just look back 3 month and assess how many of the things that happened were predictable (keeping in mind the fact that hindsight is 20/20).
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.
> The OODA loop has become an important concept in litigation,[2] business,[3] law enforcement,[4] and military strategy. According to Boyd, decision-making occurs in a recurring cycle of observe–orient–decide–act. An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly than an opponent, can thereby "get inside" the opponent's decision cycle and gain the advantage.
"Somewhat predict" is incredibly different than "make a detailed plan for". I like strategic planning in 3, 6, even 12 month increments, but doing the detailed work toward those high level plans in much shorter and less static increments.
Let’s assume you have a strategy for the next 3 months. You identified / endivisioned a need in the market and came up with a reasonable solution; you locked in the budget, you allocated the resources. How many times are you going to change these in the 3 months?
But that's not the kind of plan that comes out of these planning sessions. What you're describing is more like the effort to put together organization / unit level OKRs. That is a good thing. But getting everyone together to guess ahead of time how they'll execute that solution in detail is a poor use of time in my opinion. I think the planning exercise is useful for cross organization alignment at a high level, but for individual contributors, I think it at best makes their eyes glaze over and at worst makes them frustrated and demoralized, and then once the planning is done everyone goes back to doing the actual work, which of course doesn't match the plan very closely.
If you have a company that has more than 200 developers, there is a certain level of inertia involved in everything you do. You can’t be shifting projects nearly as quickly as when you have 10-50 developers.
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.
For example the sort of business which supplies hardware needed to write yours or mine comment. Not everyone is deploying to production every day or even every two weeks. Not everyone has feature development measured in hours.
>> I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out
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.
I’ve been there. A meeting with over 900 people, half of them in a different timezone, looped in via video feed on a big wall. Fortunately it was also my last meeting of such kind. The following 3 months were a total waste of time.
Priorities changing is one thing, but the answer to the second one is that priorities are priorities. If something to the left-side of a timeline now takes longer, it usually shifts everything else to the right. Thats just the reality of the situation, and the point is to have the awareness of the impact and be able to adjust accordingly.
You change priorities then. If a set of features takes much longer due to whatever reason, you just pare them down or postpone release accordingly. If you have important customers waiting for the release, you then first talk to them and then cut or postpone depending on their opinion and common sense. Delaying release doesn't summon demons or cause apocalypse, despite what some managers try to bs us.
I think maybe this is the confusing thing to me. What "release"? It seems like plenty of people are doing this for service-oriented software where these "releases" are totally arbitrary. Most of us are not putting CDs in boxes...
It's interesting to me that you saw this as such a success story. In my organization, people have worked hard to get it down well under three days, and to me it still feels like a ton of effort for dubious benefit, because no plan survives first contact with the enemy.
How big was the team and what type of project?
And what amount of level of detail did you put in the planning/roadmap?
Did you also had experiments and investigations taken into account?
It's difficult to really articulate just how much damage SAFe safe has done to our organization. But senior management loves the waterfall planning and the finance guys love the level of detail they can stuff into their spreadsheets somewhere.
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.
As someone who just finished a week of 8 hour PI planning meetings with another week of the same starting Monday, I wholeheartedly agree. My experience of SAFe has been shorter term waterfall with a couple steps cut out. It's definitely better than waterfall and I'm grateful for that, but I wouldn't call it agile.
SAFe almost feels like a ploy lead by waterfallistas to sneak their agenda back into the mainstream and call it "agile" to fool everyone. It's a shame because there is room for a toolkit to help scale agile. There aren't great tools for managing dependencies between agile teams.
I mentioned this in another reply, but it bears repeating. Our current PI planning is 2 weeks not counting the half day before in Pre-Planning for 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.
I have been involved in 2 medium sized-ish (~300) software support projects for western-nation's land forces project that brought in SAFe with a fanfare. Lots of ($$) training, everybody gulping down the coolade etc etc. It started off OK, but as with most of these ideological methodologies, our projects' circumstances started to clash with the SAFe 'way'. Our customer was very fond of his existing rituals (meetings, committees, progress meetings etc), but we also folded in all the SAFe rituals too. It seemed we were in meetings too much of the time, and we did a poor job of convincing the customer to move wholesale to the SAFe way. In addition, the organizational structure and governance models never operated in the SAFe way, with the customer's insistence on being in our shorts on every decision hampered most of the 'delegate decisions as deep as possible' philosophy. At the end of the day, it steel feels like RUP re-invented for 'agile' .. never again.
The thoughtworks case study is repeated. Otherwise wholeheartedly agree. I have delivered plenty of software during 10 PIs, but that was in-spite of SAFe, and the whole thing was harder and slower because of it.
Since then, I reorganized a team of ninjas away from the trains and have delivered at 3x the velocity using kanban methodology.
I worked for a company that adopted SAFe and sent me to get certified as a SAFe Program Consultant. So I worked to set up "Agile Release Trains" and coached a few teams that had never used any Agile methodology before.
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 have never worked in a SAFe environment, but have worked with multiple teams that have followed various Agile methodologies over the years, with varying degrees of "compliance to the process".
> 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.
The critique by agile experts of SAFe would be more convincing if they had shown earlier how to scale up agile.
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.
Self-organization at scale: Teal / Holacracy / Sociocracy. In the case of holacracy: Imagine a world where your company, its rules and all its employees including the bosses are bound by a constitution [0].
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.
The idea that you can scale agile is false. It's fake. Agile experts didn't say how to do it because it can't be done. They put everything they knew, as clearly as they could, in the manifesto. And then they described themselves. And almost all of them were consultants. They found that delivering software frequently to their customers worked better than any alternative.
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.
I don't really understand SAFe, but from the outside looking in, it seems like the answer to "How close can we get to agile while still employing an army of Project Managers?" Which is to say, not very.
SAFe not only keeps middle managers employed and feeling important but also forces lots of unnecessary pencil pusher type work on the engineers and designers. It's a strain on all parts of the organization that are forced to use it.
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.
I have also left an employer with MBAs that continually tried to find and mandate the One True Way of building software. I noped out when I found myself in multiple status meetings every day repeating myself to different middle managers (and having to update a Slack status channel as well). Spoiler: they adopted SAFe after I left, which told me everything I needed to know about SAFe without having to experience it firsthand.
When I read it, I see a devastating critique of SAFe from every big name I trust in the Agile space. I would never recommend SAFe. But no-one is asking 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.
My personal experience is that, while you’re absolutely right for startups, large multinationals and companies that don’t see themselves as necessarily tech-first still use it as a selling point.
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.
This seems a bit of a hit piece, but it seems like a safe target as at least half the people I know seem to hold it (SAFe) in disdain. I've consulted for organizations that started using it and have a mostly negative opinion. Organizations that are in near complete disarray may find it useful; but then again, they might also find a return to old-school waterfall useful. Where I've seen SAFe not work so well is organizations that are doing reasonably well with planning, but have some deficiencies or some corners of the organization that aren't doing too well.
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.
I’m going to summarize my earlier comment with this:
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.
SAFe is not about software development or planning. SAFe is about funding software development in a cost center. I haven't seen anyone address how to do the accounting for software development for a large organization, where that software is not being sold for money.
You are absolutely right about the short-sighted problems created by incompetent finance models.
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 view the implementation of SAfe anywhere as a huge red flag. To me it suggests that the decision makers read about Agile and what it proposes and decided that for whatever reason they don’t want it, in its unfettered form it scares them, or they don’t understand how to adopt it. As someone who prefers working in Agile workplaces, that tells me all I need to know.
My experience in an org that introduced SAFe during my time there, was that it was actually a misguided bottom-up introduction. A couple teams went agile and found it really effective then thought "if it was this effective for 1 team just imagine if we scaled it up to everyone!". Spoiler: I will likely never work for another SAFe org again.
Seems to me that SAFe like so many business ideas only exists because companies that work well without it may still work well despite having to use SAFe. Companies that don't function well are not magically turn into well-functioning companies because someone threw a book at it. When you can restructure a company from not-working to working order, it's not SAFe that did it, but someone with enough time and energy. At that point it doesn't matter if SAFe was involved or not, because that's just an idle wheel coming along for the ride.
When consultants suggest a "new" fad, they're all about charging money to help businesses adopt that fad to avoid FOMO. Predictably, there will be a new fad next year and the year after that. Waterfall: elevator control systems, agile: expense reports UI, and apply a blend to things in between.
100% agree. I worked at a large telco where this happened. Brand-name consulting company “changed methodology” half way through the project and charged the customer for it.
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.
Those who can't tend to hurl negativity and sabotage at those who do.
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.
I've never worked in an organisation that used SAFe, but to be honest I've never worked for one that used SCRUM either. The only semi-structured method I've ever been part of has been "SCRUM BUT".
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.
I had a recruiter mention to me that the company is all about SAFe and I should express my interest and enthusiasm for it during my interview. I looked it up, saw a diagram describing the process that actually made me burst out laughing and ran far away from said company.
I'm a SAFe certified SPC and RTE. Also a programmer with 20+ years of experience.
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.
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.
This post is classic SAFe and SAFe-certified trainer talk:
* 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".
> * 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),
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".
I’m not a SAFe consultant. I’m certified but I consult on a lot of things: Postgres and application performance tuning, DMARC deployment, pipeline automation and organizational process.
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.
SAFe is for managers, Agile is for developers. As developer, you don't need to know SAFe and it rituals. SAFe is not heavy weight, it very lean for the problem it solves.
> 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.
Ahhh feature flags, the sick organization’s last crutch.
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 :)
That's not feature flags. You're referring to user options that individuals or companies can enable or disable.
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.
I know Don Reinertsen and I did his training workshop a years ago.
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
In practice, all the ills that you decry as NOT SAFe, are what happen at every organization that I have been a part of that tried SAFe. The prescriptive framework and focus on process over people are the easy part, and an easy trap to fall into.
>The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall.
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.
There are two things you're saying that simply don't align here:
> 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.
>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.
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?
Thank you for helping me recognize that the hellhole I'd previously worked in in my first software dev job out of college was a SAFe gig. I'd referred to it a lot as "weaponized agile" (which I believe it is), but somehow I hadn't connected the dots of my middle manager casually mentioning safe to the inane, almost preschooler level of sticker-award-insult that strips away developers abilities to, well, do what they've spent their career learning to do and instead "gives them the ability" to "pick their own team names (and we can name our epics in a theme! :") )" (insert gratuitous "yay"s, clapping, and suggestions of how fun it will be).
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. >:')
Wow, this is the kind of comment I come to HN for. Thanks for this. There are a lot of vocal SAFe detractors, so it’s nice to hear about why it could actually be good.
I'm currently going through my second company implementing SAFe. The first one no longer does it, and I'm likely to quit here because of the adoption. You should try to experience first-hand rather than come to a conclusion from random detractors and random SAFe consultants. My single piece of data: If I poll all the software developers who I've worked with directly under SAFe, some hate it, many just live with it, but NONE are huge boosters or advocates. I think that speaks to disconnect between SAFe advertising and SAFe reality.
I did work at a company that implemented SAFe, and it was miserable. I am interested to read commentary from someone who has had a good experience, because those seem to be so rare.
I had a very good experience using safe 4.x
The whole department participated.
Edge Software
Cloud platform
Application team
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?
Some problem might be it's both a people and a process problem. There may be little to nothing about it that is objectively, technically "wrong". But maybe it doesn't work for 90-95% of people.
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.... :))
And I would just like to emphasize, most of the terms and titles you see on that slide are capital-letter Proper Nouns. The agile manifesto is more a _vibe_ about how to think about work, and how to approach the process. SAFe is a full on cult that absolutely depends on every single part on that slide doing exactly what is prescribed, or else it all falls apart.
If anyone comes and tries to sell you stuff using a chart that looks like that, better show them the door immediately. That thing seems optimized to cause upper management hypnosis by its expertly designed cavalcade of hollow bullshit terminology.
I've never seen this chart before, but I've worked with people previously that I know would get instantly giddy with excitement looking at this.
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 basically Rational Unified Process (cross-team waterfall) with a coat of Agile paint. No one in a SAFe organization thinks it's particularly agile, but it meets certain business needs (total visibility and the appearance of control by upper management).
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.
Here's a 2019 presentation from Lockheed Martin about how they are implementing SAFe for their F-16 software development. They went from throwing a whole new program over the wall to flight test in 3-4 years to delivering an testable increment (of the new program) in 9 months. Their total program delivery is no shorter, but they now get test feedback on increments years sooner.
SAFe was implemented top down at CVS Health when I was there. Main benefit I got from it was the parties in the evenings after PI Planning days were excellent.
I worked at a company where the new CTO instituted SAFe (which he used at a previously failing company).
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.”
I worked for several years at a company that was known for its use of agile. I had my critiques, but overall was a fan. Then I moved on to a much larger company and heard of SAFE, and my initial reaction was "isn't SAFE axiomatically an oxymoron?". Subsequent experience at that large company reinforced that initial impression.
The SAFe promise is that you can make your enterprise agile without any of the difficult changes that senior and middle management have to make to truly make agile. Just pay scaled agile lots of money for your project managers to become certified.
It’s like a diet that promises you can eat as much of whatever you want, as long as you pay.
As a former Thoughtworks leader who is mentioned by proxy on this website, it's pretty lightweight in how it describes the attitude towards SAFe. It was almost universally a failure in any company that adopted it. Frequently I landed business merely because a company was trying to unwind SAFe.
What SAFe does is provide some sort of visibility and accountability to senior management. (Which waterfall did before it) Until the Agile community can come up with a reliable way of identifying and firing the low performers for senior management, they will keep pushing down requirements like SAFe on the organization. Fortunately, the level of opacity between budget managers (P/L) vs execution managers usually doesn't get this bad until you've got 10 - 20K employees.
How does SAFe reliably identify "low performers"? Top companies tend not to do SAFe, I don't see the issue this solves. But I'd easily see SAFe creating low performers.
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."
In my experience, if what you've got is a months-ahead plan where management sets the deadlines AND controls the scope via pressuring the line manager, and delivery relies on crunch time and panicky de-scoping and working to the letter and not the spirit of the contract, then what you have is waterfall in a fedora and a Groucho Marx novelty disguise.
It’s well known at this point that Agile and any other “methodology” is a scam. The only thing that matters is raw IQ everything else is just kabuki paper shuffling.
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...