That's cargo scrum, very common disease. Teams without autonomy or self-organization. The queue should consist of higher level tasks, milestones, and the team should rework them into the small tasks that will actually go into sprints. Of course there is a motivation to pick the higher priority tasks first, but team members should be able to pick a task with which they can most efficiently contribute to the sprint goal, it's not always the top one.
It's main purpose is to react to changes, and make the whole process sustainable. It's literally one of the 4 main lines of the manifesto and the second of the 12 principles, and included in the meaning of the term "agile" itself, while guesswork isn't mentioned. But I can see how trying to predict what the markets will look like in 6 months involves a lot of guesswork, which is eliminated. I hope you can see that the only reason why guesswork is tricky is that there are a lot of changes in the meantime, so the ability to react to them is the deeper, actual main purpose.
No, they need to come up with that on their own. What exactly "wrong" means? And why do you think you know it better than them? What if they find some better way that you didn't know about? Agile says that it needs to be sustainable also for the sponsors. Show the team that if the sponsor isn't able to sustain the next sprint, there won't be a next sprint. The process is up to them.
We still need to explain what "agile" is. Ask yourself why do we "need" to deliver small increments at frequent pace? Isn't it to be able to react to changes?
Some engineers complain about having the ability to pick their tasks and have input in prioritization and planning? This has always been the most attractive part of agile for me. Self-organized team. Built around motivated individuals. Striving for technical excellence.
Can you point to any of the 12 principles which says that we should do "barely any testing"? I can point to some that say "deliver working software" and "it's the only valid measure of progress". If testing helps you deliver working software, then do testing, that's agile.
Agile is about reacting to changing requirements. If the requirements never change, then agile doesn't promise to be better than other methodologies. It came from a rapidly changing crashing markets in the .com bubble. How would the other methodologies fare if requirements changed two or three times in the middle of the project? That's when you need to be agile.
How did they even measure "success" if the requirements weren't given up front? What did they expect at the end?
But that implies there are a lot of good programmers among the rejected CVs.
I mean here in this example from OP - if he improves his CV visuals and then finds a job - that means he had the technical qualities to get the job in the first place, only the CV impression was causing the rejections. Which means the hiring managers are following a flawed metric, relying on shallow and easily manipulated visual factor. Every time I try to dig into this, the answer is along the lines "You need to impress the hiring manager in 10 seconds" which is a very different game than the technical skill and I don't see how would that impression translate into long term work performance. It's just gatekeeping. Nobody is quoting any statistical research, not even the hiring managers themselves, so I suspect there isn't much to back this practice. I hope someone can prove me wrong.
Is there actually any measurable relation between the colors on a CV and work performance? If hiring managers drop candidates just based on this, then I assume there must be a really strong relation, but I've never ever seen one, or even seen anyone else talk about it.
What I'm saying is that if it's really true that he is going out because "the people that matter don't think Emad was going to be able to turn it around" then it's very likely that the replacement will be more able to turn it around, because that will be the selection criteria.
That's exactly what they have been doing since the start of the invasion, and that's how they explained the cut-off when Ukraine was using the Sea Babies for the first time. So either something changed, or the article's claims are bogus. Starlink definitely has the exact location and ID of every ground terminal and can easily refuse the connection.
Apache-2.0 gives everyone those rights. The CLA makes Element the only one who can build proprietary modifications on top. Monopolization of the position they gained by advertising as open-source.
> Don't get me wrong, people will expect you to write good and clean code.
I can agree with this. Clean code is not "celebrated" because it is expected as normal. You won't get a raise for it. You could get problems for not writing clean. But when the business gets into a tight spot, they will accept shitty code that fulfills their desired goal over a nice clean and elegant solution delivered few days later. In this case, the shitty code could get you a raise.
Realistically, if they started as proprietary in the first place, they wouldn't ever grow to this size (just another closed chat app competing with Discord and Messenger), so they still benefited from being open-source. Now they are reaping the benefit and monopolizing it.
The CLA ennsures their monopoly, it increases the asymmetry over time. Forks will have to share all improvements with Element, but Element will be able to provide proprietary improvements, which means more people will chose it. Then they can at any moment relicense and take the whole app proprietary.