Usually in interviews I check if they use Jira in their day to day process. If they do, I don't join that company.
What would you use instead?
How big tech runs tech projects and the curious absence of Scrum
11–20 of 452 posts
Re: How big tech runs tech projects and the curious absence of Scrum
#12Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and continuously improving CI/CD pipeline is an expectation.
I really wish more people knew about SAFe. It’s constantly improving and refining the experience and from what I have seen, if there is a better way to do things SAFe will become it.
Re: How big tech runs tech projects and the curious absence of Scrum
#13Re: How big tech runs tech projects and the curious absence of Scrum
#14One pet peeve of mine: people often say they run a "lightweight" version of some project management philosophy and end up paying the costs of it without the benefits. For example lightweight agile scrum meaning sprints, but no retros and work constantly coming into and out of a sprint.
I'm still employed there so I guess my methodology (or lack thereof) isn't that bad ;)
Re: How big tech runs tech projects and the curious absence of Scrum
#15I occasionally see statements like this floating around - does he mean:
* Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod
or
* Devs make their changes locally, commit and push on a branch, and rapidly (ideally automatically) merge to main if tests pass. This happens on a cycle of minimum coherent set of code changes, not a whole feature at a time or anything like that.
The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. I also don't really see a drawback to the second one in comparison.
Re: How big tech runs tech projects and the curious absence of Scrum
#16My tinfoil hat theory is that Scrum was invented by Big Tech to hobble potential future competitors.
Nah, it was created to add a new industry on top of IT. Everyone is doing Agil.. I mean Scrum. So everyone need to be certified, to follow workshop, to follow the "innovation", to buy the associated toolings and so on.
Re: How big tech runs tech projects and the curious absence of Scrum
#17I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.
You certainly need to think about how long tasks will take, but there's no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.
If you have a team of people that more or less adheres to a few principles, there's no reason you can't get things done.
Re: How big tech runs tech projects and the curious absence of Scrum
#18I would say "lack of vision" is one of the key features of SCRUM.
Re: How big tech runs tech projects and the curious absence of Scrum
#19Re: How big tech runs tech projects and the curious absence of Scrum
#20The article mentions: > Scrum got in the way of shipping on a daily basis. The whole idea of Scrum revolves around Sprints, of committing to tasks at the beginning of the sprint, working on these during the sprint, and demoing what we did at the end. What if each team member came up with a few tickets to work on during let's say a 2 week sprint and then these tickets were shipped as they were finished resulting in re…
You forget that there's a big administrative load added to a two week scrum (planning, daily, daily...), that you need to test and validate, potentially validate the work with QA and do a demonstration at the end. I've never seen a two week sprint working as intended. Especially if you factor the interruption for fix, new feature discussion, task that are more complex than expected and so on. If you add a manager in…
The review at the end is for all stakeholders to be able to catch up on what's being going on the last 2 weeks.