An organization with a number of agile Scrum teams also has a small group of people appointed as "enterprise architects". The EA group acts as control and gatekeeper for quality and adherence to decisions. This leads to overlaps between the team decision and EA decisions.

For instance, the team might want to use library X or want to use REST instead of SOAP, but the EA does not approve of that.

Now, this can lead to frustration when team decisions are overruled. Taken far enough, it can potentially lead to a situation where the EA people "grabs" all power and the team ends up feeling demotivated and not very agile at all.

The Scrum guides has this to say about it:

Self-organizing: No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.

Is that reasonable? Should the EA team be disbanded? Should the teams refuse or simply comply?

10 Answers 10


A Development Team is made up of 3–9 people with cross-functional skills who do the actual work

Scrum Master should invite "Enterprise Architect" to become a part of the project team. Then the communication between architect and programmers would be excellent.

  • 2
    Good point; however I don't see how this can work if there are multiple teams that the architects work with.
    – sleske
    Commented Mar 5, 2013 at 15:56
  • 1
    "Hey, EA, now you sit over here and are still communicating with the same people. Just more often." How exactly does this help solve any of the conflicts between the EA and the other devs?
    – Izkata
    Commented Mar 5, 2013 at 18:55
  • @sleske, why don't split "enterprise architects" group between teams? or employ more architects? the problem, is does the company wants SCRUM and agile teams, or sth scrumish. Izkata, daily meetings change a lot in team's communication, seriously, when EA will feel that he/she is a part of the DT and not some extraterestrial architecture bunch, there is better chance for a compromise.
    – user83254
    Commented Mar 5, 2013 at 21:55
  • 1
    @ariwez: "why don't split "enterprise architects" group between teams?" Because we have more teams than architects; also the architects mostly work on problems that affect multiple teams.
    – sleske
    Commented Mar 6, 2013 at 9:16
  • @sleske: "Individuals and interactions over processes and tools"
    – user83254
    Commented Mar 6, 2013 at 11:59

The choice of technology used is part of the requirements of the software, which means it's part of the feature request that you don't use certain technologies, for whatever reason.

The architects speak for the systems and the codebase because the systems and the codebase can't speak for themselves. Having an architect is generally in the long-term best interests of a company, especially one which relies on software that is built in-house.

The architects aren't telling the developers how to turn the backlog into increments (sprints), they're saying which technologies can and can't be used. You're conflating two different issues.

The solution is to change nothing. If your teams are getting frustrated because the architects are too restrictive or too overbearing, that's a personnel issue that has nothing to do with SCRUM and should be taken up with the business stakeholders as an issue of employee satisfaction and, if possible, the bottom line ( "It takes us x% longer to develop features for y because architect z wont let us use Turbo Pascal." )

  • It's not about about personal satisfaction, it's about productivity, quality and caring about product value. I assume the devs in the teams can make that distinction. Commented Mar 5, 2013 at 14:21
  • 2
    Someone, at some point, made the decision that they can't. That's why the architects exist. Commented Mar 5, 2013 at 14:37
  • 4
    I'm currently working on a triple-stack server-side app mixing Rails, Java, and .NET that really didn't need to be very complicated. So yes, gatekeepers can be a good thing but tech decisions should originate with devs arriving at consensus and management approving or communicating concerns, not non-devs making arbitrary tech decisions or side-swiping dev team decisions in the middle of a sprint. Commented Mar 5, 2013 at 16:07
  • 4
    @erik And when three separate teams arrive at their three, separate, consensus decisions you might get a mixture of Rails, Java and .Net.
    – MarkJ
    Commented Nov 6, 2013 at 18:22
  • @MarkJ if you have three separate teams working in isolation for the same server-side web app, you deserve what you get. Commented Nov 7, 2013 at 0:58

This sort of thing is necessary to maintain balance between needing a large team to get the project done, and the need to keep agile teams small.

Generally, the 'team lead scrum' is composed of one member elected from each of the smaller teams. That provides some of the self-organizing nature, as well as providing some manner of representation so that decisions made by the high level group are accepted by the agile group.

For your particular scenario, something should be done to stop the agile team demotivation, but probably not rebellion or simple acceptance. The team needs to realize that you're there to make good software, not kowtow to ideals. Having a bunch of different teams each using different technologies to do similar things in the same project is going to lead to worse software. Having a bunch of different teams use different coding standards in the same project is going to lead to worse software.

So you're going to need some way to come to some consensus about how the project is going to work. The team lead scrum is used in other places effectively. You might need to do something differently, or look into why your group is not doing it effectively.

  • 2
    Sure, but turning it around: forcing all teams to use the same crappy technology is even nastier (all go down the same ugly path). Whereas having "diversity" is bound to produce at least some solutions that will thrive. Commented Mar 5, 2013 at 13:56
  • 2
    @MartinWickman sometimes there are business decisions behind choosing crappy technologies. If 80% of the developers in a particular market have experience with crappy technology, then it can make a lot of business sense to use said technology because it allows you to bring on contractors when needed. In a small market, you may not be able to find any Python programmers worth their salt. Commented Mar 5, 2013 at 13:59
  • @JonathanRich When I say crappy I mean crappy. That includes not being able to find anyone who knows it. Commented Mar 5, 2013 at 14:16
  • 1
    @MartinWickman - Sure, I'm making the minor assumption that your designated top tier developers (either assigned, or self-organized) aren't complete idiots.
    – Telastyn
    Commented Mar 5, 2013 at 14:24
  • 1
    @JonathanRich flawed business logic, IMO. Larger quantity doesn't mean higher proportion of quality and it takes a lot fewer Python devs to get the job done if they're at least competent. Commented Mar 5, 2013 at 14:57

Question is: What is reason why this Architect team exists? Only reason I can think of is to enforce interoperability between various teams. Or the teams are working on various parts of single product and this architect team exists to keep every part working together.

I really don't think this scheme can work well in agile environment, for exact reasons you say. The various teams should be self-contained and so should be their inputs and outputs. So constraining their outputs should only be as part of requirements on input. But those constraints should be reasonable. Something like "Must not use library X" is not a good requirement, but saying "Must limit number of used 3rd party libraries to minimum" or "Adding new libraries, that aren't used in other teams should be limited." should be fine.

Then I would dissolve the architect team across all teams and use their expertise in questions of architecture. By becoming part of the team, they will be able to better see problems the team is having and might have better ideas or more educated opinions about changing core parts of architecture. It should also be encouraged to architects across teams to communicate to ensure architecture remains consistent across teams.


The group over at Scaled Agile Framework speak to this really well. Most of us deal at the Team Level, but when scaling up we need to recognize that there are roles to play at the Program and Portfolio level as well. Architectural decisions need to be made across the organization, and that should feed into what is happening at the lower levels of the organization. There's nothing wrong with having architectural decisions!

Related to this, Dean Leffingwell's recent book on Agile Software Requirements is a good read on this topic, I've been reading it myself.


We also have multiple, agile teams (some do Kanban, some Scrum), and architects. The architects are responsible for infrastructure that spans all of our products (helper libraries, authentication, build infrastructure) etc. They make technical decisions, but also implement things, mostly infrastructure components.

This works well, and there's usually no conflict. I believe one crucial point is:

The architects have no formal authority over the teams, and cannot just overrule them. Normally, the architects make decisions that apply to all products, and the teams make decisions for their product. If there is a conflict, then architect & team just need to reach an agreement, or escalate to management (though that rarely happens).

I think it's really important to make architects and developers peers. Both work towards a common goal, just in different areas. If no one can just "overrule" the other, cooperation will be better.

  • 2
    Agreeing with @MartinWickman that "boundary" is the key, in several senses: firstly, the opinions of architects should be heeded in software boundaries, where components from multiple teams connect; secondary, that architects know their own boundary of authority, so that they will refrain from stepping into the team's decisions as long as the decisions do not impact interoperability.
    – rwong
    Commented Jul 7, 2013 at 22:34

I don't see any conflict here. From what I understand, all the EA (as pompous a title I think that is) is meant to do is QA. Everybody should be aware of that.

You should consider, that in any development methodology (that deserves being considered one) requirements gathering is a crucial step, whether it's iterative or upfront.

Some of these requirements are set by company policy. And these set the ground rules:

  • The team will have to abide by them as by any other requirement. Challenging the policy is then simply outside the scope of the project and should be handled separately.
  • The EA's job is to enforce these requirements and not impose their personal fancy. They don't like X then that's their personal opinion. Nothing more, nothing less. Treat it like any other opinion. However, if the EA can show that using X violates an existing requirement, then they are well within their right to forbid the use of X and if they know a workable alternative and the team doesn't, then it's their right to enforce it.

But either way, a requirement is either met or not. If that determination is hard to make, then the requirement is lacking and you need to reiterate it to become truly testable (in a broader sense). You should handle that as any requirement reiteration.

  • They're clearly doing more than QA. They're making decisions about tool use. Commented Mar 5, 2013 at 14:48
  • @ErikReppen: I was a little unclear. I meant QA is what they are supposed to do.
    – back2dos
    Commented Mar 5, 2013 at 15:04
  • @back2dos : I think you need to change QA for Standardisation. I know what you're saying, but QA is a different team entirely and confusing your point.
    – gbjbaanb
    Commented Nov 7, 2013 at 8:42

Martin, I think you may have a misconception about how a self-organizing team functions in its environment.

You quoted the Scrum Guide: "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality."

This is not a license for the Scrum team to do whatever it wants (so long as it delivers) without regard to the technology and business needs of the company as a whole, and the needs of the other teams.

Sure stakeholders can abuse their influence. That is one of the challenges of collaboration, and it's certainly not limited to the EA. But collaboration doesn't end at the boundary of the team.


Your Architect should not be overruling decisions made by your agile teams. Your architect should include these in the requirements/stories passed to the teams. They should keep teams updated when the landscape of the project changes & new interoperability requirements are introduced.

Architects giving out orders and vetting technical decisions is a cultural flaw. They see themselves as the "boss" rather than simply maintaining a shared goal/vision & keeping separate teams on the same page. Agile methodologies are based on communication & contact. When your architects don't get involved until after decisions are made, they're failing at agile.

  • "When your architects don't get involved until after decisions are made, they're failing at agile." - If we inverse this statement: "When the team does not involve the Architects when making decisions, then the team is failing at agile." If there are decisions being made by the team that are a change in technology, existing patterns, etc... then the team needs to include an Architect to ensure the overall product remains cohesive. Commented Apr 3, 2016 at 22:18

Waterfall or Scrum (this seems like mixing two, which yes, is not going to work), that sounds like a pretty pointless layer of management to me in the first place. Gatekeepers on technology decisions should be lead devs, the overall manager of development whose job should be to keep dev preferences from turning your app into a hydra of tech choices, and whoever's budget has to foot the potential bill.

Nothing continues to dumbfound me like non-devs actually having the gall to make technology decisions without even consulting the actual people who have to suffer the consequences of those decisions.

  • This reads more like a rant than an answer. Commented Dec 29, 2017 at 21:51
  • Someone has to do it. Commented Jan 10, 2018 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.