My Redmond Developer News column went up last week. This month I talked about the danger of having one person be the Scrum Master and the Architect/Tech Lead.
Here’s a small quote:
In a well-performing, healthy Scrum team, the Scrum Master is there to help the team be productive by functioning as the keeper of the process and the slayer of impediments. The Scrum Master watches what’s going on and tries to help the team self-organize and deliver the features that the Product Owner thinks are valuable. A key responsibility is to eliminate any impediments and help the team deliver software that meets its Definition of Done.
When you’re the software architect (or the lead developer), you’re very concerned with exactly *how* things get implemented. You probably care about everything from the database design to the Domain Model to the unit tests to the user interface. You are usually the ultimate arbiter of code quality and coding style, ensuring quality and consistency in the code base. All that prescriptive "how" gets in the way of letting the team self-organize and decide how to tackle the work.
-Ben
-- Looking for help making your Scrum team more productive? Having problems with software architecture in an Agile/Scrum world? Want to do Scrum with Team Foundation Server 2010 (TFS2010)? Drop us a line at info@benday.com.
