The Role of the Architect in Scrum

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.

Advertisements

About Andre Simones
I am a founding partner of One80 Services that specializes in agile training, small business and startup guidance, and custom development. My goal is plain and simple. To see others succeed. I want to teach you how stop doing the things that aren't working and give you tools that will empower you to succeed on your own.

One Response to The Role of the Architect in Scrum

  1. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: