The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I 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.…
Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile". When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel. If you don't, or do "Scrum but not quite", then when things don't quite work out,…
How big tech runs tech projects and the curious absence of Scrum
291–300 of 452 posts
Re: How big tech runs tech projects and the curious absence of Scrum
#292Earlier quoted context omitted.
But is there evidence the force is actually multiplied in practice?
Pretty sure there isn't, otherwise FAANG would enforce it top down. They already enforce other practices top down like hiring etc, so if they had data saying that mandating Scrum would make the company X% more efficient they would absolutely do it. It might be a force multiplier in other types of companies, but it probably isn't in FAANG style companies. Similar to how FAANG hiring can make sense to them but still be…
Re: How big tech runs tech projects and the curious absence of Scrum
#293First of all, I work at Amazon (and posting this under our social media policy, this is just my experience, and I don't speak for the company), and Scrum is pervasive at Amazon. The article is right that many big projects start with a 6 pager, but once teams start executing, many teams run some form of Scrum (Kanban is also popular).
The second thing I found strange in this article was the idea of Scrum being heavy-weight. Early in my career I worked at a small company where our process guru was a big fan of the Unified Process. The point of Scrum is that it is lightweight (without being zero process). There really isn't a lot to it. You sync with your teammates daily, to make sure you're all focused on the most important thing today. You check in every 1-4 weeks by (a) demoing your software to figure out where you are, (b) you do a retrospective to look at what can be done better, (c) you figure out what is the most important thing to be doing the next N weeks. The teams that I've been on that have tried to not do these things either in actuality, did these things, but did them subconsciously, and therefore unintentionally. When I hear people say "Oh, I don't like Scrum because my old team did Scrum and I didn't like how we..." what follows is almost inevitably something that if you asked a professional scrum coach "Should we do that?" the answer would be no.
> Competent, autonomous people need less structure to produce reliable, high-quality output. Big Tech is able to attract, afford and hire these people.
I don't like this way of thinking. Start-ups have lots of competent, autonomous people. Big Tech companies have lots of people early in their careers that are still learning to be autonomous. In fact, when I was at start-ups I often heard the opposite (and equally untrue) claim: that start-ups required people with more autonomy, because the product is new and the team is involved in discovering the product, whereas in larger companies the products are more defined, so people needed less autonomy.
I appreciate the author surveying people and trying to make sense of the results, but in this case I think he just over-simplified a much more complex reality in a way that isn't particularly helpful.
Re: How big tech runs tech projects and the curious absence of Scrum
#294Earlier quoted context omitted.
SAFe is just waterfall management with agile keywords tacked on. It's not an engineering methodology. The only "problem" SAFe solves is reintroduction of deadlines and quarterly objectives, which flies in the face of everything agile actually stands for.
It doesn’t do any of those things. The quarterly PI’s are for planning because the most you can reasonably plan for with any degree of accuracy is about 8-12 weeks. There are no deadlines imposed. You plan what you’re going to work on and how long it will take. You coordinate with other teams for any dependencies they may need from you and when. But you as a developer are responsible for saying how long it will take…
Which amounts to estimating software deliverables beyond the scrum window, which will invariably lead to disappointment, which will eventually fallback upon the shoulders of devs. It is impossible for delivery dates beyond the estimation horizon to not start being used by management as an anchor at some point in the near future. It only takes one manager promising stuff for the rest of the management team to try and emulate the savior.
Teams coordination only requires timely backlog priority management and does not need to be planned top-down for days on end with all members of all teams present.
Re: How big tech runs tech projects and the curious absence of Scrum
#295The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I 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.…
I suspect the prescriptivism and detail have one end goal and that is for someone that has no idea how software is done to follow the procedures. It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt. You also have to deal with people who needs to be told which shoe to put in first before they think the process is "confusing". Same reason for PMP, it'…
This is not just a scrum problem. Any agile process eventually reports to a layer of management that doesn't think in agile terms, and wants their PERT charts or whatever. The impedance mismatch at that boundary is one of the biggest difficulties with implementing agile.
Re: How big tech runs tech projects and the curious absence of Scrum
#296Shape Up: mentioned for a few venture-funded companies. Has anyone here some experience with Shape Up? Love to hear your thoughts. I just read about it so far and would love to hear some real-life stories.
Re: How big tech runs tech projects and the curious absence of Scrum
#297The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I 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.…
Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile". When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel. If you don't, or do "Scrum but not quite", then when things don't quite work out,…
> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.
So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?
Re: How big tech runs tech projects and the curious absence of Scrum
#298Earlier quoted context omitted.
Sometimes importance is related to size. Points are arbitrary, but lets assume that on average a developer will work the entire sprint on an 8 point task. The PM might decide that feature is not worth the time investment in that sprint, if they could instead get 2 smaller features out the door, or some bug fixed - they might prefer to deliver that to stakeholders. That's why there's even a velocity expressed in point…
Bugs get resolved desk-side five minutes after being reported and pushed through on PRs that have 89% test coverage (still green!). Developer is a cowboy hero! The good thing is: you always get more bugs like this so everyone gets a chance to be a hero.
Re: How big tech runs tech projects and the curious absence of Scrum
#299Earlier quoted context omitted.
Every company I've worked at that followed some sort of rigid scrum process has suffered from burnout and general failure in one form or another It treats developers like consultants because it's really designed for agencies working on one-off short-burst projects ( this is the only setting I've seen it have a positive effect ) by nature it just chews people up if it becomes a day-to-day practice, the whole process r…
> the whole process revolves around the assumption that there's lack of trust and team cohesion Where in Scrum is this defined?
Re: How big tech runs tech projects and the curious absence of Scrum
#300Earlier quoted context omitted.
Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile". When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel. If you don't, or do "Scrum but not quite", then when things don't quite work out,…
>Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team…