Why the ScrumMaster Should Be neither the Architect nor the Manager
I’m often involved in a broad array of companies in which the manager of the development team is also the architect as well as the ScrumMaster. The managers of these groups are most often convinced that this method of organizing the development team is working very well. At the companies I’ve had opportunities to dig into further with I’ve almost always discovered that this isn’t the case, and the team frequently suffers from a general sense of powerlessness. Design decisions are taken out of the hands of those doing the work, their manager consistently plays the role of the smartest person in the room, and the team members aren’t comfortable speaking up. When issues are brought up in retrospectives they tend to be disregarded, as the ScrumMaster cannot act as an advocate to solve management problems. Since the feedback loop is fundamentally broken these managers create a closed loop of feedback in which they believe the team is functioning perfectly. The end result is that the manager continues to drift further away from reality (as the team sees it) until a sudden implosion occurs and the manager is taken off guard.
The roles of the ScrumMaster and the architect are critical, both of which should be active peers on the team helping remove road blocks. There should be no hesitation in the team members feeling empowered to bring problems to the folks in these roles or speaking up during the retrospective process to ensure that continuous improvement is being achieved.
It is my continued and strong belief that senior technical peers on Scrum teams should serve as the product architects. They should never be part of the reporting structure, but clearly in a position where the big picture design is part of their direct responsibility and planned into the user stories themselves. Their job is largely to ensure success of the product and trust within the team. However, when done properly, the entire team perceives them as helping each and every team member be more successful; this is good for the individual, the team, the product,