Scrum Masters are not Administrators

Lately I was asked if I was interested to work as Scrum master. The below job description was handed me over. What an experience it was. 

The text with the regular font is the job description. I wrote down my comments in italics.

• Manage team of software engineers: provide technical direction, schedule and delegate work, evaluate performance, advise on best practices and developing practice, review code A Scrum master empowers a development team. The team schedules the work during each Sprint. The team members select the stories they will implement next. The Scrum master advices best practices but he really should not perform code reviews and police the team. He does not manage and certainly not micro-manage engineers. He shall never evaluate performance of team members. He shall not police the team by reviewing code.

• Analyze requirements and provide time estimates: consume non-technical functional requirements documentation, provide feedback when necessary, translating into technical documentation when necessary, provide feasibility assessment and estimate level of effort to implement The product owner and the team writes and refines stories. Avoid requirements and move to stories and epics. Technical documentation and feasibility assessments shall be done by the team. And only the team has the right to estimate the effort needed to implement a story. The Scrum master is neither a business analyst defining requirements nor a project manager creating schedules and time estimates.

• Help develop, communicate and enforce workflows: work with Development department head and QA to assure that clear workflows are established and followed within the team An agile team has quality assurance roles as cross-functional capabilities. You do need a quality assurance team. Dissolve the quality assurance department, move their specialists to the teams and get rid of the vice president of quality assurance. The Scrum master does neither administrate flow of information nor implement processes. He trusts and coaches his teams to deliver best quality.

• Coordinate with QA, IT Operations, and Database Administrators on testing, launch planning, launch, and troubleshooting/optimization of features post-launch. The product owner plans the release schedule with the team. A high quality product does not need a troubleshooting process. The above nicely describes an organization based on functional silos. No cross-functionality is ensured and product focus is an unknown concept. The Scrum master is neither an administrator nor an overall coordinator. His teams are self-organizing and directly communicate with all involved parties

• Architecture: participate in technical design of new and expanding systems and infrastructure; aid in creating documentation for new and existing systems The team grows the architecture and implements the solution. Not an external so-called expert shall be in charge of the architecture or sole owner of the design. The Scrum master is neither in charge of the architecture nor the external expert imposing his views on the team.

I clearly decided not to apply for this position. I was fascinated that companies still believe that such alibi positions will not be detected. The above position is a flag for me. As an agile developer, Scrum master or product owner I shall never work for this company. I will have no fun at this workplace.

They were looking for an administrator and a classical project manager. They were not looking for an agile professional and Scrum master.

I kindly suggested the authors of the job description shall get an introduction training to Agile, Lean and Scrum. And I will certainly not recommend this company to my acquaintances.