3 ms·

I recently made a transition from a company focused on scrum to a FAANG working the way above. A lot of comments here are saying that engineers in this system c

I recently made a transition from a company focused on scrum to a FAANG working the way above. A lot of comments here are saying that engineers in this system can just do whatever they want without constraint. I think what people are missing is the focus on documentation that FAANG have in contrast to the focus on in person meetings in scrum. Things like sizing and planning get done in the initial stages of a project. The design docs and plans are peer reviewed and only once it has been signed off on does the actual implementation start. During implementation you have much autonomy but this is because most of the details have already been ironed out. The code is almost an afterthought. This has been my experience so far but also at a lower than senior level. So take it with a grain of salt. Also deadlines feel looser. Things regularly get pushed back quarters because of dependencies on other teams. Because there is no real fear of the company collapsing. It's okay we just work on something else.

64StarFox64 4y ago
How much of this is possible due to the fact that "there is no real fear of the company collapsing?" This sounds like process-resembling-waterfall, which seemingly works well because use cases, constraints, and patterns are (relatively) so well understood at an established company. Is there "edge" or value in that process, or is the value in the understanding of use-cases, constraints, and patterns (or a drive to align towards reaching said understanding) that enables the process?
- aleksiy123 4y ago
  I think the second "the value in the understanding of use-cases, constraints, and patterns (or a drive to align towards reaching said understanding) that enables the process" These companies operate at a different scale, speed and constraints to other companies. Just as people say "you are not Google" don't use Google tech solutions for your problems. Don't use FAANG processes for your use case without understanding why those processes are the way they are. As an addendum to my first comment I want to also say that no scrum does not mean no processes. In fact there is a lot of processes. The number one complaint is that there is too much processes. They are just not scrum. There is no one size fits all solution which is what the product "Enterprise Scrum" tries to be. Teams need to understand their needs for themselves and build/iterate on a set of processes that works for them. Large orgs need to enable this as well as set the baseline for processes that work across the whole org at every level (indivudual -> team _-> product area -> organization).
  - 64StarFox64 4y ago
    Ok, thanks for your insight.

64StarFox64 4y ago

How much of this is possible due to the fact that "there is no real fear of the company collapsing?" This sounds like process-resembling-waterfall, which seemingly works well because use cases, constraints, and patterns are (relatively) so well understood at an established company. Is there "edge" or value in that process, or is the value in the understanding of use-cases, constraints, and patterns (or a drive to align towards reaching said understanding) that enables the process?

aleksiy123 4y ago
I think the second "the value in the understanding of use-cases, constraints, and patterns (or a drive to align towards reaching said understanding) that enables the process" These companies operate at a different scale, speed and constraints to other companies. Just as people say "you are not Google" don't use Google tech solutions for your problems. Don't use FAANG processes for your use case without understanding why those processes are the way they are. As an addendum to my first comment I want to also say that no scrum does not mean no processes. In fact there is a lot of processes. The number one complaint is that there is too much processes. They are just not scrum. There is no one size fits all solution which is what the product "Enterprise Scrum" tries to be. Teams need to understand their needs for themselves and build/iterate on a set of processes that works for them. Large orgs need to enable this as well as set the baseline for processes that work across the whole org at every level (indivudual -> team _-> product area -> organization).
- 64StarFox64 4y ago
  Ok, thanks for your insight.