This question comes up over an over, so I thought I'd address it quickly.
Remember that in an ideal Scrum team, the team is completely self organizing. There are no titles to worry about. The team will discover the strengths and weaknesses of each member, and continuously evolve, i.e. inspect and adapt, to discover new ways of delivering high quality value to the business.
But, guess what. In the real world, we have titles to deal with. Now, I don't think that's such a bad thing.
As we all know, the title "Architect" in the context of software means very different things given the organization. I've seen it range from really good coder to more of a project manager-y type of position. I think this lack of clear role in the industry overall has lead the folks in this title to, at times, become "chickens" that like to cluck and flap their wings to distract the team.
So, what should the architect do? Well, let's remember that in Scrum, team are self organizing. They collectively come up with the technical solutions. They also come up with development standards. If the team is generally not high performing, or are missing some necessary skills, then the architect should be a mentor and a coach for that team until they can fly on their own.
What if the teams are high performing? If there is an organizational need due to a highly complex business need, i.e. insurance, taxes, financial transactions, etc., then the architect should focus on the high level roadmap to ensure that the backbone of the technology is strong. This is especially true in a SOA environment.
Tuesday, December 29, 2009
The Role of the Architect in Scrum
Subscribe to:
Post Comments (Atom)
1 comment:
Another great post Andre. I agree with you here that the ideal is a 100% self-organizing team. I've seen the architect fit in well as more of a product owner than a member of the Team. In this way, he or she can ensure conformance to the high level project vision, and help point out potential roadblocks or major issues in complex environments. As you say, SOA is one example. Another is where you have a lot of applications integrated via an integration layer. Regardless, the architect can be the one to ensure that the Teams think of the implications on other systems.
Post a Comment