31–40 of 452 posts
"Teams struggling often had little to do with the methodologies. People mentioned lack of vision." I would say "lack of vision" is one of the key features of SCRUM.
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.…
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, you're on your own.
I'm no fan of Scrum, and rather use almost anything else, but that doesn't change that there's significant value in using systems that are mostly figured out and "work". 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. At that point you're better off just doing your own things. Which is what folks do, they abandon Scrum and do agile their way.
> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I 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,…
The 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…
It wasn't forgotten. Maybe the places I've done contract work for didn't follow scrum to a T. There was no daily planning. It was meeting once for 2 hours every 2 weeks to figure out what to work on and then a few small teams self regulating themselves asynchronously until things were done. This included doing the work, updating the ticket, having at least 1 person review / test the PR and it getting released. Usually there was a 1-3 day turnaround time from the PR being set to review to it being live on the site. Could be longer if the PR needed a lot of changes from things caught in the review process but the ball was always moving.
It never killed a single developer's productivity to wait on a review because every developer had a few tickets to work on during that 2 week process so they could jump to the next one or review another person's PR in the mean time.
There was no manager component once the tickets were chosen for the sprint (which was often a manager + developer group effort). Code could go from a ticket to production with no administrative bottlenecks.
> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I 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,…
Software engineers need more rigid structures and stop thinking they're in a park trying out new technologies!
> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I 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,…
For larger features, these changes could be stacked in a list. After each change in the list had been approved, they’d be landed on main as an all or nothing.
> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I 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,…
So yes, you work locally on a fork of the repo but not the main/master repo. I'd surprised if all devs have access to push to main/master.
I think having branches leads to a lot of merging issues. Because technically, the branch will then be used by multiple devs. So it's like dealing with multiple masters, kind of.
Personally, I prefer the TF approach. Oh I forgot to mention, the release tags are branches I think, perhaps read only branches.
> Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business. In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the…
Usually in interviews I check if they use Jira in their day to day process. If they do, I don't join that company.
It is a fuck-ton of work to set Jira up so it gets out of the way, but it has all of the customization I need to serve most of everyone’s needs.
If anyone so much as thinks about enforcing workflows on our scrum board, they are going to hear my polite, but firm, rejection of such meddling. It’s our board and we let other people see it so they don’t have to bug us with requests for status updates.
Jira isn’t a hard no for me because I’ve been an admin for it at both this job and my previous one. Let my team manage our stuff, and I’ll happily set up Jira to keep everyone else’s grimy paws off my team.