Does a Scrum Master need to know something about software development?
Moin.
Advertisement
(Bild:
)
Stefan Mintert works with his customers to improve the corporate culture in software development. He currently sees the greatest potential in leadership; regardless of a hierarchy level. He gave himself the task of leveraging this potential after a career path with a few changes of course. Originally coming from a computer science background with several years of consulting experience, he initially founded his own software development company. He discovered that leadership has to be learned and good role models are rare. It became apparent that the greatest need for support from his customers in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was headed: improve leadership so that the people who develop the products can develop and grow themselves. Stefan has been writing for Heise as a long-time freelancer for iX since 1994.
Today I’m trying to find an answer to the question. “Does a Scrum Master have to know something about software development?”
The way the question is asked, my answer is: no. But firstly, it doesn’t hurt if he or she knows something about it, and secondly, it depends on what you consider software development to be. I will explain it with an example.
Internal communication is essential for successful team collaboration. So a Scrum Master does a good job when he pays attention to communication and, if necessary, works on it with the team. I assume this statement is general enough that every reader agrees.
What gets exciting is the question of where communication takes place in a software team. Trivial answers include meetings like Daily Scrum, Review, Retrospective, Refinement and so on.
And what about pull requests?
Pull requests are an important part of team communication. I’ve worked with teams that were peaceful and tame in meetings, but fought real battles in pull requests; a single punch and stabbing. The “good” programmers versus the “bad” programmers. Blaming and fingerpointing like from the textbook. Nothing that was even less than “perfect” was accepted. (The fact that perfectionism is one of the astonishingly many paths to hell is a topic for another blog article.) Pull requests sometimes dragged on for weeks.
The result? Team members were silenced and were no longer able to move independently. They focused on self-protection and no longer on productive work. Commitments in planning? It was extremely rare.
What does this have to do with the Scrum Master?
If the Scrum Master takes the view that he should avoid the software source code like the devil avoids holy water, he is missing out on this part of team communication. Since putting someone down is easier in the somewhat more protected space of the pull request (writing instead of speaking, asynchronous instead of synchronous, not face-to-face) than in team meetings, this negative behavior can develop like a smolder for a long time. When the flames appear, it is (too) late and the hut is literally burning; and the Scrum Master is surprised.
When I work with a software team, I also occasionally look at a few pull requests. Recently I wanted to do this for a client and was amazed that I didn’t have access. There were only a limited number of licenses for the system in use, and no license had been purchased for the Scrum Master. Thought too short.
What can I do as a developer?
A solution is simple: invite the Scrum Master to (some) pull requests. If you work at a company that is afraid of licensing costs, you should commit to spending the money. Whatever works: Process the pull requests together with the Scrum Master as in peer programming.
Bye. Stefan
(rme)
To home page