[HN Gopher] The SAFe Delusion
___________________________________________________________________
The SAFe Delusion
Author : clockworksoul
Score : 202 points
Date : 2022-10-29 14:56 UTC (8 hours ago)
(HTM) web link (safedelusion.com)
(TXT) w3m dump (safedelusion.com)
| cpeterso wrote:
| 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.
|
| https://www.youtube.com/watch?v=nvfYLZ52zX0
| csours wrote:
| 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.
| ethbr0 wrote:
| Internal billing + discretionary "keep the lights on"
| budgeting?
|
| It has its flaws, but it's not the worst approach.
| roguecoder wrote:
| 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.
| 63 wrote:
| 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.
| roguecoder wrote:
| It follows the outline of taylorism, just one level up from the
| team: measure, control and manage.
| tootie wrote:
| 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.
| rileyphone wrote:
| I strongly agree with this, but you need some more editing,
| especially to convince the leadership types that keep making this
| mistake.
| nvr219 wrote:
| Agreed. The decision makers at my company would not read this.
| cpeterso wrote:
| And if you're going to say "Don'tdo SAFe, you sure suggest some
| alternatives.
| brightball wrote:
| 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.
|
| 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.
| skeeter2020 wrote:
| 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".
| delusional wrote:
| > * 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".
|
| It's unfortunately a very effective strategy.
| brightball wrote:
| 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.
| drran wrote:
| 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.
| flerchin wrote:
| 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.
| namdnay wrote:
| 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 :)
| asplake wrote:
| 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
| ketzo wrote:
| 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.
| skeeter2020 wrote:
| 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.
| ChuckMcM wrote:
| 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.
| bitwize wrote:
| > What SAFe does is provide some sort of visibility and
| accountability to senior management.
|
| This is true of all Agile methodologies adopted by
| corporations.
|
| If it weren't true, the methodology would not be adopted.
| ResearchCode wrote:
| 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.
| ethbr0 wrote:
| By mandating visibility.
|
| 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."
| twawaaay wrote:
| 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.
|
| Talk about crazy projects...
| closeparen wrote:
| 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.
| SSLy wrote:
| SAFe is bad, but is there anything better when you have, say,
| 1500 devs, and expect two fat releases a year with whatever
| required bugfixes between?
| Smeevy wrote:
| Doesn't that fundamentally undercut the incremental value
| delivery and CI/CD progression that SAFe promises?
| yakshaving_jgt wrote:
| > is there anything better
|
| Yes. Not doing SAFe.
| faangiq wrote:
| 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.
| i_like_apis wrote:
| heisenbit wrote:
| 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.
| kitsune_ wrote:
| 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.
|
| [0] https://www.holacracy.org/constitution/5
|
| [1] http://scrumbook.org/ and
| https://sites.google.com/a/scrumplop.org/published-patterns/...
| ineptech wrote:
| 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.
| vesinisa wrote:
| 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.
| bane wrote:
| 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.
|
| 1 - https://en.wikipedia.org/wiki/Conway's_law
| _fat_santa wrote:
| 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.
| jffhn wrote:
| >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.
| quickthrower2 wrote:
| 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.
| RajT88 wrote:
| 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).
| marcosdumay wrote:
| Getting everybody together once in a long while, and
| synchronizing a "what are you working on?" is a good
| exercise.
|
| But only if that while is long.
| quickthrower2 wrote:
| I am in two minds about leads only vs. everyone. Obviously
| both have advantages.
| lee wrote:
| 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.
| tonyarkles wrote:
| 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.
| 29athrowaway wrote:
| I like this take on SAFe. Steve Denning has great talks about
| what agile is, and what it is not.
|
| 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.
| synu wrote:
| It's agile for companies that absolutely do not want to adopt
| agile but want to be able to tell their (prospective) employees
| that they have.
| ResearchCode wrote:
| Are employees looking for "agile" companies? Seems more like
| a red flag for micromanagement nowadays.
| synu wrote:
| 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.
| 29athrowaway wrote:
| That is a nice way to describe it.
|
| SAFe puts a bunch of layers between you and the customer.
|
| Agile is about removing layers between you and the customer.
| charbull wrote:
| 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?
| JulianMorrison wrote:
| 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.
| rootusrootus wrote:
| 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.
| ButterWashed wrote:
| 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.
| cpsns wrote:
| 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.
| ethbr0 wrote:
| I worked for a SAFe company like that once.
|
| 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.
| orzig wrote:
| I read as much of the site as I could, but could somebody
| explain: how is SAFe different than the original agile manifesto?
| fidrelity wrote:
| The agile manifesto does not dictate any team or organisational
| structure.
|
| 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.
| db48x wrote:
| I'm having an allergic reaction after looking at that chart.
| Where did I put that epipen?
| gherkinnn wrote:
| Very lean indeed.
| isoprophlex wrote:
| 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.
| [deleted]
| flerchin wrote:
| 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.
| bitwize wrote:
| 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.
| brightball wrote:
| 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.
| sas224dbm wrote:
| 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.
| dunno7456 wrote:
| This is a reflection of agile brin dead on the water when it
| comes to it's promises.
| retrocryptid wrote:
| 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.
| swagtricker wrote:
| Don't forget the classic parody of SAFe which shows it as the
| overblown "waterfall in agile clothing" that it is: LAFABLE.
| https://www.lafable.com/
| mkw2000 wrote:
| 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.
| yborg wrote:
| 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.
| onli wrote:
| 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.
| roguecoder wrote:
| 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.
| heynowheynow wrote:
| 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.
| doctor_eval wrote:
| 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.
|
| True story.
| oneplane wrote:
| 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.
| mindwok wrote:
| 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.
| electrondood wrote:
| 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.
| JamesSwift wrote:
| 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.
|
| Can you tell I'm not a fan?
| quickthrower2 wrote:
| 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.
| hef19898 wrote:
| 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...
| ResearchCode wrote:
| 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.
| tapatio wrote:
| Same. I found it to be very effective, especially having a
| bunch of release trains in sync. Obviously this applies to
| large organizations.
| bl4ckm0r3 wrote:
| 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?
| kqr wrote:
| > 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?
| Yizahi wrote:
| 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.
| tonyarkles wrote:
| > 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".
| ThalesX wrote:
| 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.
| pflenker wrote:
| 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.
| ethbr0 wrote:
| > _Those who cling to plans are at disadvantage against
| those who have the ability to quickly adapt to the
| change._
|
| https://en.m.wikipedia.org/wiki/OODA_loop
| doctor_eval wrote:
| > 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.
| kgwgk wrote:
| "In preparing for battle I have always found that plans
| are useless, but planning is indispensable."
| hef19898 wrote:
| 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.
| tikhonj wrote:
| 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.
| hef19898 wrote:
| 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.
| roguecoder wrote:
| 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.
| hef19898 wrote:
| Not everything is a consumer facing app, you know?
| SpicyLemonZest wrote:
| 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.
| mvdwoord wrote:
| I would honestly like to reverse this question...
|
| 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?!
| tikhonj wrote:
| 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?
| kqr wrote:
| 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.
| marcinzm wrote:
| 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.
| roguecoder wrote:
| Collective code ownership is a prerequisite to most Agile
| processes for this very reason.
| marcinzm wrote:
| 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.
| theptip wrote:
| 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.
| tonyarkles wrote:
| > 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...
| skeeter2020 wrote:
| >> 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.
| tsimionescu wrote:
| What happened when two months in the priorities changed, or
| when a feature that looked like it might take a turned out to
| take a month?
| JamesSwift wrote:
| 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.
| Yizahi wrote:
| 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.
| mrweasel wrote:
| 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.
|
| [1] https://www.infoq.com/presentations/Predictable-Failures/ (At
| around 24:30 and a few minutes from there).
| 29athrowaway wrote:
| Scrum is not an acronym.
___________________________________________________________________
(page generated 2022-10-29 23:00 UTC)