An Architect in the Agile World


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,

User Comments

1 comment

About the author

Jonathan  Wiggs's picture Jonathan Wiggs

<p><strong>Jonathan Wiggs</strong> has been working in the software industry for over 20 years working with the latest technology. He has held roles from being an individual contributor on research and development projects to leading shipping products as a Vice President of Technology and Engineering. Jonathan brings his passionate approach and diverse experience to many companies both large and small. In recent years he has focused on launching technology endeavors at startup companies; and brining his expertise in security, .Net, and database technologies to his writing and his teaching. Currently Jonathan is the Sr. Product Architect at Netmotion Wireless Inc. Jonathan can be reached at <a href=""></a> for correspondence or comment.</p>

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!