A common complaint in organizations adopting Scrum is that Scrum has too many meetings. However, people may not be considering all the time they spent meeting before Scrum—and how effective that time really was. As long as you keep meetings focused, people should waste less time in meetings than they did before Scrum.
The degree of confidence in your knowledge may vary, often due to the process you went through to learn the concept. An understanding of how different learning techniques affect the depth of your knowledge can help you with how you process information you already have and how to approach learning new things.
A common problem for Scrum teams is having a good understanding of what work is complete by the end of the sprint. Teams often end with a few items coded but not fully tested, but since the goal of a sprint is to have a deliverable increment of work, skipping tests isn’t a good idea. Here's how you can fit them in.
In project management, it's easy to focus on details to the extent that you lose track of the larger goal. Scrum can help you identify flaws and gaps, and skipping or trivializing Scrum events will just hide the fact that there are things you need to improve. Finding problems is something to be celebrated, not hidden.
Self-confidence is essential to tackling difficult problems. Where we need to be careful is not being falsely overconfident. What’s behind that overconfidence can either help or hinder your solving issues and achieving a good result. Here's how to make sure that confidence is backed up by competence in your team.
Is your process for pull requests compromising your team's agility? You can structure your changes in a way that facilitates more rapid feedback, but even then it is still possible to have a slow integration time if people don’t review pull requests promptly. Mechanics are part of it, but culture also matters.
Pull requests may not seem to fit into agile development, but they can work well if done right. If you can maintain feedback on your working software from frequent integration, using PRs can help people understand your code. The speed at which PRs can be reviewed depends on three things: context, size, and atomicity.