Earlier quoted context omitted.
As a Dev, I loved SAFE. It changed everything about how our program operated to the point our delivery became extremely predictable and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. That program purred like nothing else I've ever been a part of. Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen befor…
> and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. We do PI planning from SAFe. We would get the last sprint of quarter for slack, improvements, they said. Instead, we use it to clean up the mess created from waterfall scrum in the previous sprints.
How big tech runs tech projects and the curious absence of Scrum
341–350 of 452 posts
Re: How big tech runs tech projects and the curious absence of Scrum
#342The 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.…
Re: How big tech runs tech projects and the curious absence of Scrum
#343Earlier quoted context omitted.
> the whole process revolves around the assumption that there's lack of trust and team cohesion Where in Scrum is this defined?
A mandatory meeting in which all developers must be present and regurgitate status updates to the entire team, as an example, assumes this information wouldn't get to relevant parties organically and all team members must consume all status updates.
This is because nobody can be assed to figure out who needs to communicate with who, on what.
Re: How big tech runs tech projects and the curious absence of Scrum
#344Earlier quoted context omitted.
The issue with all of this addition process, ceremony and meetings is work still needs to get done. Sadly the only time to do work is often outside of working hours since then, finally, the meetings and ceremony have ended.
I don't think this is the case. A two week sprint should have about 100 minutes of standup, 1 hour of planning, 1 hour of refinement, half an hour of review and 1 hour retro, ish (I can't remember the exact timings). About 5 hours every 2 weeks. Saying that adds up to a full 2 weeks of work is just... pointless. So falsifiable.
In the end, it was just so obviously unworkable to everyone it had to be stopped.
However, you are absolutely right, we were not in meetings 100% of the time - it just felt like it. Many people need good swaths of uninterrupted time (perhaps 1.5-2 hours minimum) in order to be productive. Rapid context switching between various meetings and development work can be expensive. It is unfortunate when this time can only be found outside of working hours.
My suggestion is to start with no process and no regular meetings and carefully add process/meetings as required. If you need to talk with one or more people... call them right now (or arrange a meeting with a clear agenda - right now). All overhead should be carefully evaluated in terms of its actual ROI.
Re: How big tech runs tech projects and the curious absence of Scrum
#345The 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.…
The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…
I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds
The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop.
I learnt retros from Google. Big tech does retros. Its honestly magic when done well.
Re: How big tech runs tech projects and the curious absence of Scrum
#346Earlier quoted context omitted.
> debating whether it is worth 5 points are 8 I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on. I think you are right that much of…
A couple things: 1. Sometimes your team needs to give an estimate of when it will deliver a feature. The idea of pointing in Scrum is that you establish a velocity, which lets you get a feel for how long it's going to take to deliver a given piece of work. 2. Sometimes your team needs to make trade-offs, and often the right lens here is ROI. You can't estimate ROI if you don't estimate the I. (Although I believe agil…
Re: How big tech runs tech projects and the curious absence of Scrum
#347Earlier quoted context omitted.
> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."
I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't chang…
Re: How big tech runs tech projects and the curious absence of Scrum
#348The 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 thought one of the interesting points in the article was that Scrum gives a team some breathing room when there are many "stakeholders" in the organization wanting feedback, updates on progress, and to frequently change requirements. The Sprint gives a defined time period during which the team is allowed to work uninterrupted by these kinds of requests, with the updates, feedback, change requests etc. taking place…
Re: How big tech runs tech projects and the curious absence of Scrum
#349My tinfoil hat theory is that Scrum was invented by Big Tech to hobble potential future competitors.
Why make up an easily debunked conspiracy theory?
Scrum wasn't invented at big tech..
Agile development in general became a thing in the mid-90ties.
Re: How big tech runs tech projects and the curious absence of Scrum
#350Earlier quoted context omitted.
A general goes to the commander of a group of soldiers and says "In 3 months, I want them to be able to demo the "march in formation" feature in front of the big-wigs who decide whether to give us more funding." So the commander says "Yes General, we'll do Drills™ to make it happen." And then the commander writes down "Do drills" on a TODO list, gives presentations to the soldiers about the importance of drills, and…
But lots of developers actually hates Scrum even when done correctly. The problem is that Scrum is very rigid, it tells you how long your development cycle should be, what your meetings should look like etc. They'd prefer to just do what needs done, have the meetings that needs to be had, deliver features when ready rather than have arbitrary deadlines (sprints) etc. I understand that many developers loves having tha…
Now, it might be that some people selling Scrum have Very Specific Views about some of these things, but that's not Scrum either.