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.
Scrum, the popular Agile framework widely used in software development, follows a life cycle that is by nature satisfying to work through because of its structure. If you're wondering why it's more satisfying than other pure frameworks for project management, it's because you have been trained from childhood to love a good story. The Sprint cycle, the time-boxed period during which the team works to deliver a potentially releasable product increment, follows a similar structure to one of the most satisfying literary frameworks - the hero's journey.