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.
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.
In the world of Agile development, SAFe has become a popular framework for organizations to adopt. However, some people believe that SAFe is just Waterfall with an Agile twist. They claim that SAFe is just a translation of Waterfall into the Agile world. But, these people are wrong. SAFe is built from the ground up on Agile principles, not a mere translation of Waterfall. To understand SAFe and its origins, it's essential to look at the history of Agile. Agile was born in the 1990s, as a response to the slow, bureaucratic nature of Waterfall. The Agile Manifesto was written in 2001 by a group of software development leaders, who recognized the need for a new way of working that… Continue reading Is SAFe Really Just Waterfall?
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.
A friend of mine recently pointed me in the direction of a video by YouTuber No Boilerplate that argues that Scrum is not Agile and that developers should not estimate their work or plan their work out, and the only metric they should use is functioning software. While I agree with the idea that we should try to minimize distractions that take away from developers doing their work, I believe that the video's creator is far too idealistic in their approach.