231–240 of 452 posts
Earlier quoted context omitted.
I think they mean when your retro board has a theme; I've seen various themes applied successfully i.e. sailboat: https://metroretro.io/templates/the-sailboat-retrospective
Is it just me or does this look great for a 2nd grade class.
I have teams that respond well to it. People like me, who work in metaphors and abstractions, respond well to it.
So the key takeaway here is that the Plan, build(iterate), ship cycle works very well. Most successful teams stick to this. What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say. So how do you fit in this new requirement ? You are already in the middle of a feature built on day 3 or 4. Devs are working…
Earlier quoted context omitted.
You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.
Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
There’s this image that big tech teams build software where everything is automated and has 100% test coverage and all the infrastructure heals itself and all teams are hyper efficient. It’s not really true, the biggest shared practice between big tech is letting the team’s manager pick whatever methodology works best for them. The big tech version of scrum is just sprints, stand ups and shipping often. There’s still…
I think your last point is wrong. Shipping big, complex projects at big tech companies, especially vendors who actually literally ship and can't do live patching to cover up shoddy practices, is actually something _everyone_ in the industry should do because you learn a lot about what it really means to build and release software. Cloud-delivered CRUD apps are the easy mode of SW development and people who have never…
I actually agree with your first point too, I do think big tech devops and security practices should be copied.
The point I was trying to make is that I don’t think big tech management is actually that good. Big tech is optimizing for staying big (reliability, security, etc.) the famous projects are usually the most uninteresting to engineers cause they ship a handful of new features a year and you spend most of your time working on bug fixes, infrastructure updates and security patches so those projects end up having the most churn in engineers and management. Because of that churn these teams tend to adopt the practices most suited to oversight (stand ups, sprints, retrospectives, etc.) instead of the ones best fit for improving the customer experience (grooming the backlog, collecting user feedback often, etc.). So that’s why I say we shouldn’t be using big tech management practices as an example imo, cause big tech still hasn’t decided on a solution to the problem of slipping deadlines, exploding backlogs and insurmountable technical debt.
Earlier quoted context omitted.
You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.
Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.
> 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…
My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no process" from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and…
Earlier 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…
Exactly. Managers look for metrics and point and velocity are what they use. Well anyway, managers in my current company are dumber than second coat of paint and I inflate points.
It's not a coincidence the consultancy sector uses scrum. They get paid for their output, usually by the hour, and scrum measures output.
If a consultant implements a load of useless features that make a product worse, but do so very quickly, then that's a great success for them. It's not fundamentally different from rewarding developers for the number of lines of code they write.
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.…
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…