As software professionals, we need to work continuously to improve our skills. But two common challenges are how to best work to improve, and how to find the time to learn when we’re busy. The answer is deliberate practice—practice with a clear goal and defined measures for success that pushes your usual boundaries.
The ways we listen—and not listen—are detailed in the Five Levels of Listening model, which goes from most distracted to most focused. Ideally, we’d all practice the fifth level: empathic listening, where we try to understand what matters to the person who is speaking, delaying our problem-solving and responsiveness.
Some kindergartens are experimenting with new approaches to teaching, including letting students form groups to accomplish tasks that interest them, which also allows them to support and engage with each other. This is self-organization, the heart of Scrum. If five-year-olds can do it, your agile team likely can, too!
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.