From the time I started as a Scrum Master, I have had the opportunity to personally witness several different organizations' Scrum implementations, and discussed with others their experience with Scrum at their organization. Every organization does it slightly different, but that's OK. Some have been outstanding, and have inspired me to try many new things to solve problems on my Scrum teams. But, for every great example of successful Scrum implementations I have experienced, I've heard of several others where I'm baffled about how loosely their implementation follows Scrum. In those cases, I often hear people suggest switching to Kanban as a solution because they just don't think Scrum is working. Let me be clear: Switching to Kanban because your Scrum implementation sucks is a lazy and bad solution.
Category: career advice
Don’t Make Your Scrum Master a Manager
Listen, I get it. At surface level, it's easy to see similarities between a Scrum Master and a traditional manager. Both are there to bring out the best in developers. Both accountabilities keep an eye on the big picture and help the team succeed. It's a common mistake for upper management to make, especially when looking at the budget and trying to cut costs wherever you can. If you're looking for a team of un-motivated developers who will do work at a snail's pace, have narrow visions for the products they are working on and are secretly looking for other jobs that will better fulfill them, then sure - make their manager do the Scrum Mastering. But if you want a team of dedicated, talented developers who will go the extra mile to make the product the best that it can be, you better keep those roles separate.
What Part of ‘Be a Servant Leader’ Don’t You Understand?
As a Scrum Master, it is frustrating to see so many people misunderstand the accountability. You are not a task master. You are not micromanager. The main descriptor of the Scrum Master accountability is to be a servant leader, which means serving the needs of the Scrum team and leading them to success by guiding them to the best behaviors using encouragement and introspection. Unfortunately, some Scrum Masters think that as long as the end results of ensuring projects are delivered on time, it doesn't matter about having good working relationships with the development team. This is wrong. If you have this mentality, you are yourself an impediment to your team's success.
Diffusion of Responsibility in a Scrum Team
Diffusion of responsibility is a phenomenon that can occur in any work setting including on a Scrum team where each team member feels that they are not individually responsible for the outcome of the product they are working on and thus they may not put in their best effort. It can show up in any meeting accompanied by long silences when questions are asked by a Product Owner, Scrum Master or perhaps a senior developer who takes on more than their fair share of the work. In a remote world, this problem can easily be compounded by keeping cameras off in meetings. This can easily become a destructive anti-pattern in a Scrum team because it can lead to decreased accountability, reduced motivation, and ultimately a decrease in team performance.
The Importance of Change
Change is inevitable. It’s a part of life that we cannot avoid, no matter how hard we try. It can be difficult to embrace, especially if it involves significant life changes like starting a new job, moving to a new city, or having a child. It's chaotic by nature. But, as Petyr Baelish in Game of Thrones famously said, "chaos is a ladder." Change forces us to adapt and overcome a certain amount of stress in order to reach a new equilibrium. Change is often hard to endure, but it can lead to positive outcomes, especially if you lean into it.