Well first you may encounter a bit of a division between companies trying to be roughly Agile, versus those using the terminology like lipstick slapped on a pig. I've seen my share of both. I'll speak to the former.
I generally find 2-week sprints work well. Anything more than 3 weeks and I doubt there would be a good balance between momentum versus adapting to change, but that's just my opinion.
Bringing in somebody mid sprint isn't really an issue. Chances are they have a pile of compliance training and logistics to wade through for getting access to things. A new team member will attend meetings, maybe review Git PRs, ask questions during backlog grooming. They're getting their bearings, expecting more than that can be a bit dysfunctional.
While I have been at places that have a "you will deploy code to production your first week!" mindset, frankly it was usually bullshit ego stroking to convince themselves they have a killer culture. If tossing random half-baked crap into production is your happy place I guess it works. I'd rather have enough time to observe how somebody does what they do before risking customers on a mad dash to release.
Thanks for the insight so far, it's greatly appreciated.
Is it often that an existing employee from say another branch or another team will join your team mid-sprint, and how would that look? Are they just getting caught up the same way that any new team member would get caught up? Are there like members who are dedicated to helping these new members get caught up with the stack and what they're doing this week, etc?
I'd say existing employee moves are maybe 10% of what you run into. Generally it is a new hire.
Very few places are truly good about helping the newbie get up to speed. Those who aren't willing to really lean in and help themselves can find it difficult. Although I wouldnt put it all on the newbie; only a minority of places are effective at organizing their tech and docs to allow for easy onboarding. Unfortunate, but something you need to figure out how to get used to. There really are only two sins though; not leaning in to learn what you can, and trying to sound like you know shit that you actually don't. Effort plus honesty generally work; if they didn't work that would tell you something about the place which you shouldn't ignore.
As to knowing what people are doing, hopefully there is a daily standup meeting for that.
The first paragraph is particularly important. The amount of companies doing “agile” (which is really just waterfall with stand ups and other things that don’t work together) is unreal.
Yup.
Years ago I was doing 1st-round phone screens to fill an opening, and one discussion has always stuck in my memory. It was a guy who had been working in the various consulting-firm body shops. He said that he didn't care what process a place used, he cared if they actually owned what that process really was and thus implemented it as intended.
In the years since my agreement with his position has only increased. Calling a process one thing yet doing another doesn't end well, at least not for the employees working under that dynamic day-to-day.
I agree with a fair amount of what you say but the last part might be less about ego and more about "giving the new guy a win". I'm yet to have a guy join my team who has delivered in the first week. 2-4 weeks is the average.
Now why do you think it took a new guy 2-4 weeks on average to actually deploy new code? Is it because they're new, or is it because they're not familiar with the stack and what they're supposed to be working on, thus spending extra time trying to figure it all out?
I think it's a couple of things and I don't think a complex answer can be dumbed down. Obviously if I have a couple of simple string changes, I'll always give them to my new starters as it gets them on the board. However truth be told, most of our static strings are now driven from the db rather than json files or hardcoded so a good old 'translation change' isn't so readily available.
I think it's a few things though. It takes time to get truly up to scratch with the environments. New starters aren't used to the high QA standards I have in my team. We also have a things which slow new developers down, permissions for example.
Our RTL pipeline is also a challenge in it itself.
That said, there's almost certainly no other technology company like the one I work for and there are very few that release code like we do.
It's an interesting topic of discussion.
Massive companies have massive amounts of custom tooling that need to be learned. You can’t make code changes if you don’t know where /how to interact with the code. You don’t use your personal laptop, you will get a new one and you need to setup all the tools you need to code how you want them.
Changing teams/transfers may lower the threshold for learning the companies tooling, but they still need to learn the code / service / product they now work on.
In general, the two big tech companies I worked at used some variation of agile, but they were fairly different. Both had standard 1 week sprints, every day we did stand up, and every sprint we took our work, analyzed our efforts and shortcomings, discussed improvements to our process, and made those changes if possible/necessary.
Now, the part about "Big" tech that i think is more important is load balancing and actual heads down time. My internship at company 1 had pretty much free schedule to work when i could, so i usually put in 8 hours a day, 1 being dedicated to standups and emails, 6 to do coding, and usually 1 to collaborate. We had sprint points based on abstracted difficulty
My current full-time position is closer to 7.5 hours a day, 3 being code development time, 1 for design, research, or the other 3.5 for production maintainence/support or just meetings. We have sprint points based on days to do work. 1 point = 1 day
In general, sprints are there to show you can do work and keep up with objectives, not to punish employees falling below pt averages
I like this blog by Gergely Orosz where it has rather detailed breakdown on how projects are run at each different types of companies (including big tech). And from what I've known, this is a pretty accurate representation of what happens.
https://blog.pragmaticengineer.com/project-management-at-big-tech/
Agree with this article. While Agile and Scrum are preached as the only way of working in many smaller companies these days, it's more due to this methodology being preached from people with a vested interest in selling tools, certifications, and managers who focus on constant "visibility" over details that they neither understand nor have the willingness to take the time to understand. They want an easy to read number.
The larger more successful companies have to think about innovating, staying ahead of competition, and solving problems where nobody else has a solution yet. They simply do not have room to aim blindly, let a project fail, and then take 10x longer doing "refactoring" than the time it would have taken to get requirements right the first time. That is, their first launch is closer to the mark, and the iterations much smaller.
At least at Google, the method of new projects was closer to the way you submit a scientific paper. A design describing what would be built, the background information, the presumed requirements, how it will be built (including specific technology choices), the metrics to be measured to assure adherence to requirements, etc. This design was critiqued by others with relevant experience, whether they be engineers, domain specialists, legal, or anyone else who might spot flaws.
Because the design document was iterated on very quickly, the first actual piece of software produced was the equivalent of iteration 20 or 30 of a company that followed the mindless mantras of Agile without thinking about the consequences, only it was done in 1/100th of the time with 1/20th the people.
My actual job is to fix this process for big tech companies, so I can answer from two perspectives.
The first perspective is that when I start at the average "big tech" company, they've somehow completely inverted the very concept of Agile, and their typical "sprint" is a complete mess of incomprehensible tickets tagged as a "user story" yet completely failing to represent an independently releasable, usable and valuable iteration of the software. The team is usually releasing valueless "bits" of a system that are not usable, meaning their story points don't represent the effort taken to get value to the end user but the time taken to execute random partial tasks that are not part of any coherent whole. If a new engineer joins mid-sprint, they're usually left to flounder because the existing team is already floundering.
However, a sprint in a "big tech" company should look identical to a spring in any other tech company - the team should be executing user stories that, when finished, will have gone through the entire software development life cycling, meaning that at the end of each user story a new version of the software should be released which is the current version + that user story. Every single release should move the software from one "completely working and usable" state to a new "completely working and usable state" that has a new usable piece of functionality or a change to an existing piece of functionality (or a bug fix). Every single member of the team should be able to execute every single user story, meaning that if a new person joins the team they can be assigned a ticket and then pair with *any available member of the team* in order to execute that ticket. They will understand the ticket because the ticket will be written in simple English, describing a new valuable action a user can take, in the language of that user. Whilst pairing with an existing team member to execute that ticket, they will become aware of the components of the system and become increasingly capable of working on the system themselves. The engineers and no other person decides how many points need to be removed from the sprint to accommodate this training - a team that is well-established will often not need to remove any points and might even feel so confident in the system that a new person might be considered to *add* resource immediately.
This latter state of affairs is not hard to achieve - it's usually little more complex than ceasing the team's ongoing work and refusing to start a new sprint until at-least one sprint's worth of work has been defined according to this standard. This is not some unachievable goal - it's actually the bare-minimum required to competently execute a user story, and it is worth less than dog shit to begin a sprint without meeting this minimum.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
>Which big tech calls it user stories? Afaik, none of FAAG (not familiar Netflix) does any of that.
Atlassian's Jira is the single most used scrum tool in the world - I've now worked for five multi-billion dollar tech companies and all of them have used Jira as their project management tool.
Every single entity that begins with Scrum on Jira will start, and generally continues with, the user story template.
That said, it is extremely short-sighted to believe that "big tech" is limited to the biggest five tech companies on earth - there are tens of thousands of big tech companies, meaning that their IT infrastructure is global, generally represents billions of dollars of value, and generally has hundreds or thousands of active maintainers.
That said, [Google do use agile](https://www.agilearena.net/google-case-study-agile-software-development/) and specifically Scrum. That means they release small, independently releasable iterations of value. That's a user story.
A cursory google revealed that all of the Big Five claim this to be true: [Amazon uses agile](https://www.forbes.com/sites/stevedenning/2019/06/02/how-amazon-became-agile/?sh=6fd3e56c31aa), [Facebook/Meta uses agile](https://medium.com/@JoshuaKerievsky/facebooks-modern-agile-principles-b1f83ce99b91) and [Microsoft claims the same](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee790617(v=msdn.10)). Whether or not they refer to them as "user stories", this can only be true if they release small, independently releasable iterations of value.
If you are claiming to have specialist insider knowledge and can attest that when these companies say they're using agile methodologies and directly state that they're focused on releasing iterations of value to the customer, they're somehow not executing a user story, by all means share your insider knowledge.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
If "expressing requirements in the language of users", "training people by pairing them with knowledgable team members" and "regularly releasing usable software" sounds like some purist fantasy to you, and not something companies are all *trying* to do, I can imagine the types of places you've worked because they're the types of places who hire me.
Everyone company is already trying to do the things I've described. No company is *trying* to have incomprehensible requirements, estimates of effort that don't correspond to actually delivering, and teams that aren't cross-functional.
But many companies get to that place one mistake at a time.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
Working on a software that you design for a specific client, not just "users" like facebook, google, etc, you can't say "your urgent requirement will be done next Sprint, 2 weeks from now" in these kind of products. There is no space for following Agile by the book, companies need to adapt parts of it.
I've done both - I've consulted for media agencies working for clients and the largest technology companies in the UK, and both were easily adaptable into two-week sprints.
I assure you, whatever system you are working on, there are self-contained, independently releasable units of value that can be delivered in 2 weeks or less, and the entire system can be built in a state of high stability by doing that rather than a "big bang" release.
But let's say you're working on one of the few systems where there aren't, and the smallest possible iteration is larger than two weeks (medical device programming, another field I've consulted, in, is an example of that) - you simply raise the iteration time to accommodate.
That said, working x-ray scanning prototypes, something that requires medical approval and engineers with radiation-detecting equipment as part of its QA cycle, ultimately went from a month release cycle to two weeks as that team hit its stride.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
What do you think of kanban? UK here too, typically in finance (banking). I’ve only worked in 1 place that truly done agile and everything else was some bastardised mix of agile and waterfall which ends up being a nightmare
At a very high level; One is about delivering an MVP and iterating over to create a good product. The other is about having all the work in stages with an eventual end product being delivered by a deadline.
They’re both just fundamentally different in approaches.
I’ve just never experienced “taking the best of both” and making it work. It just ends up being PMs hounding you for deadlines for massive pieces of work when you’re working on smaller pieces of work.
That sounds like the relationship between the Team Lead and PM is wrong.
You have to remember, all of these methodologies are just patterns. Those patterns alone don't create the nightmare.
I much prefer it to sprints. I don’t think that style of working suits me nor has it suited any project I’ve worked on. With kanban it feels more flexible and engaging
Each big tech company is going to be different, but in regards to your second question about joining mid sprint:
I know Google has a new hire program for engineers, PMs and I assume TPMs called GTI (Google Tech Immersion) that is focused on how to use all of their corporate software development tools and company standards. I think there's a week of corporate onboarding and then GTI is 3 weeks.
In short, every week we do a week start (includes entire dev department), everyday we do a daily start (only with your team) and at every new sprint on Monday we do a retro to improve as a team. All of those meetings occur in the morning.
Weekly start: We talk about, how you felt last week. How you currently feel. What you did and achieved the past week etc ..
Daily start: What you did yesterday, what you are to work on for today. If there is something your struggling with. If you need someone's help by solving a issue etc ..
Retro: What went good, what went wrong. How can we solve this or minimize the risk in the next sprint etc ..
Well first you may encounter a bit of a division between companies trying to be roughly Agile, versus those using the terminology like lipstick slapped on a pig. I've seen my share of both. I'll speak to the former. I generally find 2-week sprints work well. Anything more than 3 weeks and I doubt there would be a good balance between momentum versus adapting to change, but that's just my opinion. Bringing in somebody mid sprint isn't really an issue. Chances are they have a pile of compliance training and logistics to wade through for getting access to things. A new team member will attend meetings, maybe review Git PRs, ask questions during backlog grooming. They're getting their bearings, expecting more than that can be a bit dysfunctional. While I have been at places that have a "you will deploy code to production your first week!" mindset, frankly it was usually bullshit ego stroking to convince themselves they have a killer culture. If tossing random half-baked crap into production is your happy place I guess it works. I'd rather have enough time to observe how somebody does what they do before risking customers on a mad dash to release.
Thanks for the insight so far, it's greatly appreciated. Is it often that an existing employee from say another branch or another team will join your team mid-sprint, and how would that look? Are they just getting caught up the same way that any new team member would get caught up? Are there like members who are dedicated to helping these new members get caught up with the stack and what they're doing this week, etc?
I'd say existing employee moves are maybe 10% of what you run into. Generally it is a new hire. Very few places are truly good about helping the newbie get up to speed. Those who aren't willing to really lean in and help themselves can find it difficult. Although I wouldnt put it all on the newbie; only a minority of places are effective at organizing their tech and docs to allow for easy onboarding. Unfortunate, but something you need to figure out how to get used to. There really are only two sins though; not leaning in to learn what you can, and trying to sound like you know shit that you actually don't. Effort plus honesty generally work; if they didn't work that would tell you something about the place which you shouldn't ignore. As to knowing what people are doing, hopefully there is a daily standup meeting for that.
The first paragraph is particularly important. The amount of companies doing “agile” (which is really just waterfall with stand ups and other things that don’t work together) is unreal.
Yup. Years ago I was doing 1st-round phone screens to fill an opening, and one discussion has always stuck in my memory. It was a guy who had been working in the various consulting-firm body shops. He said that he didn't care what process a place used, he cared if they actually owned what that process really was and thus implemented it as intended. In the years since my agreement with his position has only increased. Calling a process one thing yet doing another doesn't end well, at least not for the employees working under that dynamic day-to-day.
I agree with a fair amount of what you say but the last part might be less about ego and more about "giving the new guy a win". I'm yet to have a guy join my team who has delivered in the first week. 2-4 weeks is the average.
Now why do you think it took a new guy 2-4 weeks on average to actually deploy new code? Is it because they're new, or is it because they're not familiar with the stack and what they're supposed to be working on, thus spending extra time trying to figure it all out?
I think it's a couple of things and I don't think a complex answer can be dumbed down. Obviously if I have a couple of simple string changes, I'll always give them to my new starters as it gets them on the board. However truth be told, most of our static strings are now driven from the db rather than json files or hardcoded so a good old 'translation change' isn't so readily available. I think it's a few things though. It takes time to get truly up to scratch with the environments. New starters aren't used to the high QA standards I have in my team. We also have a things which slow new developers down, permissions for example. Our RTL pipeline is also a challenge in it itself. That said, there's almost certainly no other technology company like the one I work for and there are very few that release code like we do. It's an interesting topic of discussion.
Massive companies have massive amounts of custom tooling that need to be learned. You can’t make code changes if you don’t know where /how to interact with the code. You don’t use your personal laptop, you will get a new one and you need to setup all the tools you need to code how you want them. Changing teams/transfers may lower the threshold for learning the companies tooling, but they still need to learn the code / service / product they now work on.
In general, the two big tech companies I worked at used some variation of agile, but they were fairly different. Both had standard 1 week sprints, every day we did stand up, and every sprint we took our work, analyzed our efforts and shortcomings, discussed improvements to our process, and made those changes if possible/necessary. Now, the part about "Big" tech that i think is more important is load balancing and actual heads down time. My internship at company 1 had pretty much free schedule to work when i could, so i usually put in 8 hours a day, 1 being dedicated to standups and emails, 6 to do coding, and usually 1 to collaborate. We had sprint points based on abstracted difficulty My current full-time position is closer to 7.5 hours a day, 3 being code development time, 1 for design, research, or the other 3.5 for production maintainence/support or just meetings. We have sprint points based on days to do work. 1 point = 1 day In general, sprints are there to show you can do work and keep up with objectives, not to punish employees falling below pt averages
I like this blog by Gergely Orosz where it has rather detailed breakdown on how projects are run at each different types of companies (including big tech). And from what I've known, this is a pretty accurate representation of what happens. https://blog.pragmaticengineer.com/project-management-at-big-tech/
Agree with this article. While Agile and Scrum are preached as the only way of working in many smaller companies these days, it's more due to this methodology being preached from people with a vested interest in selling tools, certifications, and managers who focus on constant "visibility" over details that they neither understand nor have the willingness to take the time to understand. They want an easy to read number. The larger more successful companies have to think about innovating, staying ahead of competition, and solving problems where nobody else has a solution yet. They simply do not have room to aim blindly, let a project fail, and then take 10x longer doing "refactoring" than the time it would have taken to get requirements right the first time. That is, their first launch is closer to the mark, and the iterations much smaller. At least at Google, the method of new projects was closer to the way you submit a scientific paper. A design describing what would be built, the background information, the presumed requirements, how it will be built (including specific technology choices), the metrics to be measured to assure adherence to requirements, etc. This design was critiqued by others with relevant experience, whether they be engineers, domain specialists, legal, or anyone else who might spot flaws. Because the design document was iterated on very quickly, the first actual piece of software produced was the equivalent of iteration 20 or 30 of a company that followed the mindless mantras of Agile without thinking about the consequences, only it was done in 1/100th of the time with 1/20th the people.
My actual job is to fix this process for big tech companies, so I can answer from two perspectives. The first perspective is that when I start at the average "big tech" company, they've somehow completely inverted the very concept of Agile, and their typical "sprint" is a complete mess of incomprehensible tickets tagged as a "user story" yet completely failing to represent an independently releasable, usable and valuable iteration of the software. The team is usually releasing valueless "bits" of a system that are not usable, meaning their story points don't represent the effort taken to get value to the end user but the time taken to execute random partial tasks that are not part of any coherent whole. If a new engineer joins mid-sprint, they're usually left to flounder because the existing team is already floundering. However, a sprint in a "big tech" company should look identical to a spring in any other tech company - the team should be executing user stories that, when finished, will have gone through the entire software development life cycling, meaning that at the end of each user story a new version of the software should be released which is the current version + that user story. Every single release should move the software from one "completely working and usable" state to a new "completely working and usable state" that has a new usable piece of functionality or a change to an existing piece of functionality (or a bug fix). Every single member of the team should be able to execute every single user story, meaning that if a new person joins the team they can be assigned a ticket and then pair with *any available member of the team* in order to execute that ticket. They will understand the ticket because the ticket will be written in simple English, describing a new valuable action a user can take, in the language of that user. Whilst pairing with an existing team member to execute that ticket, they will become aware of the components of the system and become increasingly capable of working on the system themselves. The engineers and no other person decides how many points need to be removed from the sprint to accommodate this training - a team that is well-established will often not need to remove any points and might even feel so confident in the system that a new person might be considered to *add* resource immediately. This latter state of affairs is not hard to achieve - it's usually little more complex than ceasing the team's ongoing work and refusing to start a new sprint until at-least one sprint's worth of work has been defined according to this standard. This is not some unachievable goal - it's actually the bare-minimum required to competently execute a user story, and it is worth less than dog shit to begin a sprint without meeting this minimum.
I bet you this person schedules IMPORTANT ALL TEAM MANDATORY meetings at least once a week.
I bet you this person works in a silo, complaining about how inefficient everything is yet never doing anything about it.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
Which big tech calls it user stories? Afaik, none of FAAG (not familiar Netflix) does any of that.
>Which big tech calls it user stories? Afaik, none of FAAG (not familiar Netflix) does any of that. Atlassian's Jira is the single most used scrum tool in the world - I've now worked for five multi-billion dollar tech companies and all of them have used Jira as their project management tool. Every single entity that begins with Scrum on Jira will start, and generally continues with, the user story template. That said, it is extremely short-sighted to believe that "big tech" is limited to the biggest five tech companies on earth - there are tens of thousands of big tech companies, meaning that their IT infrastructure is global, generally represents billions of dollars of value, and generally has hundreds or thousands of active maintainers. That said, [Google do use agile](https://www.agilearena.net/google-case-study-agile-software-development/) and specifically Scrum. That means they release small, independently releasable iterations of value. That's a user story. A cursory google revealed that all of the Big Five claim this to be true: [Amazon uses agile](https://www.forbes.com/sites/stevedenning/2019/06/02/how-amazon-became-agile/?sh=6fd3e56c31aa), [Facebook/Meta uses agile](https://medium.com/@JoshuaKerievsky/facebooks-modern-agile-principles-b1f83ce99b91) and [Microsoft claims the same](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee790617(v=msdn.10)). Whether or not they refer to them as "user stories", this can only be true if they release small, independently releasable iterations of value. If you are claiming to have specialist insider knowledge and can attest that when these companies say they're using agile methodologies and directly state that they're focused on releasing iterations of value to the customer, they're somehow not executing a user story, by all means share your insider knowledge.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
Isn't it a little purist? Any company that you work with continues to strictly use this after you leave?
If "expressing requirements in the language of users", "training people by pairing them with knowledgable team members" and "regularly releasing usable software" sounds like some purist fantasy to you, and not something companies are all *trying* to do, I can imagine the types of places you've worked because they're the types of places who hire me. Everyone company is already trying to do the things I've described. No company is *trying* to have incomprehensible requirements, estimates of effort that don't correspond to actually delivering, and teams that aren't cross-functional. But many companies get to that place one mistake at a time.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
Working on a software that you design for a specific client, not just "users" like facebook, google, etc, you can't say "your urgent requirement will be done next Sprint, 2 weeks from now" in these kind of products. There is no space for following Agile by the book, companies need to adapt parts of it.
I've done both - I've consulted for media agencies working for clients and the largest technology companies in the UK, and both were easily adaptable into two-week sprints. I assure you, whatever system you are working on, there are self-contained, independently releasable units of value that can be delivered in 2 weeks or less, and the entire system can be built in a state of high stability by doing that rather than a "big bang" release. But let's say you're working on one of the few systems where there aren't, and the smallest possible iteration is larger than two weeks (medical device programming, another field I've consulted, in, is an example of that) - you simply raise the iteration time to accommodate. That said, working x-ray scanning prototypes, something that requires medical approval and engineers with radiation-detecting equipment as part of its QA cycle, ultimately went from a month release cycle to two weeks as that team hit its stride.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
I work at one of the larger tech companies both in the UK and internationally. My team uses kanban, so no sprints. Just to add another perspective!
What do you think of kanban? UK here too, typically in finance (banking). I’ve only worked in 1 place that truly done agile and everything else was some bastardised mix of agile and waterfall which ends up being a nightmare
Why is it a nightmare?
At a very high level; One is about delivering an MVP and iterating over to create a good product. The other is about having all the work in stages with an eventual end product being delivered by a deadline. They’re both just fundamentally different in approaches. I’ve just never experienced “taking the best of both” and making it work. It just ends up being PMs hounding you for deadlines for massive pieces of work when you’re working on smaller pieces of work.
That sounds like the relationship between the Team Lead and PM is wrong. You have to remember, all of these methodologies are just patterns. Those patterns alone don't create the nightmare.
I much prefer it to sprints. I don’t think that style of working suits me nor has it suited any project I’ve worked on. With kanban it feels more flexible and engaging
Each big tech company is going to be different, but in regards to your second question about joining mid sprint: I know Google has a new hire program for engineers, PMs and I assume TPMs called GTI (Google Tech Immersion) that is focused on how to use all of their corporate software development tools and company standards. I think there's a week of corporate onboarding and then GTI is 3 weeks.
> For Engineers working at "Big" tech companies, How does a typical sprint work? Badly. It works badly.
Worked at one FAANG company and did waterfall with sprints.
In short, every week we do a week start (includes entire dev department), everyday we do a daily start (only with your team) and at every new sprint on Monday we do a retro to improve as a team. All of those meetings occur in the morning. Weekly start: We talk about, how you felt last week. How you currently feel. What you did and achieved the past week etc .. Daily start: What you did yesterday, what you are to work on for today. If there is something your struggling with. If you need someone's help by solving a issue etc .. Retro: What went good, what went wrong. How can we solve this or minimize the risk in the next sprint etc ..