6 ms·

SAFe seems to be a bit like "internet scale", it's designed for very large organizations building very large single software solutions. Most organizations wildl

by bane 4y ago

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 https://en.wikipedia.org/wiki/Conway's_law

RajT88 4y ago
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 4y ago
  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 4y ago
    I am in two minds about leads only vs. everyone. Obviously both have advantages.
  - jimmaswell 4y ago
    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.
- coredog64 4y ago
  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.
  - com 4y ago
    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.
jffhn 4y ago
>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 4y ago
  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.
_fat_santa 4y ago
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.
- drran 4y ago
  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.
lodovic 4y ago
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.
- steve1977 4y ago
  > 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.
pieterr 4y ago
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks

by bane 4y ago

RajT88 4y ago

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 4y ago
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 4y ago
  I am in two minds about leads only vs. everyone. Obviously both have advantages.
- jimmaswell 4y ago
  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.
coredog64 4y ago
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.
- com 4y ago
  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.

jffhn 4y ago

>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 4y ago
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.

_fat_santa 4y ago

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.

drran 4y ago
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.

lodovic 4y ago

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.

steve1977 4y ago
> 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.

pieterr 4y ago

"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks