For distributed teams, activities usually get scheduled based on constraints such as availability and time zone, but people don’t often take into account when the most effective time to meet would be. Neglecting people’s work tendencies and schedule preferences could make it harder for the team to be successful.
Managers may frame one-on-one meetings as a way to “support employees” and check to see if the employee “needs to meet this week.” Supporting an employee is a primary goal of these meetings, but the value of one-on-one time to managers—and the importance of building trust with employees—also should be prioritized.
Scrum and other agile methods focus on team roles and dynamics, and because of the emphasis on self-organizing teams, there’s sometimes a misconception that there’s no need for a manager. In reality, good people management can help an agile team thrive—the manager just has to know how to empower the team.
The limits of a tool may lead us to realize that we are not working as effectively as we can, and often, changing a tool is part of the solution. But there are good and bad ways to select a tool and how you use it. In particular there are risks when you focus first on tools before considering the problem.
Many organizations are reluctant to introduce new tools or technologies, or even to update existing ones. The reason is often framed in terms of risk management, but agile teams already have the tools to manage the risk of change: testing and experiments. These approaches together eliminate gaps in risk identification.
Agile software development works because of continuous feedback at various levels, and the most important form of feedback is working software. One way to achieve rapid feedback is to integrate and deploy code frequently. Rather than starting with the process, first decide what "frequently" should mean for your team.
Some agile teams have so fully embraced the idea of the development team owning quality that they don't hire anyone with a testing background, instead making software engineers responsible for all phases of quality. Still, testers add value to a team in many ways that don’t involve test execution. Where do they fit in?