Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

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.

share|improve this answer
2  
Good point; however I don't see how this can work if there are multiple teams that the architects work with. –  sleske Mar 5 '13 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 Mar 5 '13 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 Mar 5 '13 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 Mar 6 '13 at 9:16
    
@sleske: "Individuals and interactions over processes and tools" –  user83254 Mar 6 '13 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." )

share|improve this answer
    
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. –  Martin Wickman Mar 5 '13 at 14:21
1  
Someone, at some point, made the decision that they can't. That's why the architects exist. –  Jonathan Rich Mar 5 '13 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. –  Erik Reppen Mar 5 '13 at 16:07
2  
@erik And when three separate teams arrive at their three, separate, consensus decisions you might get a mixture of Rails, Java and .Net. –  MarkJ Nov 6 '13 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. –  Erik Reppen Nov 7 '13 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.

share|improve this answer
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. –  Martin Wickman Mar 5 '13 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. –  Jonathan Rich Mar 5 '13 at 13:59
    
@JonathanRich When I say crappy I mean crappy. That includes not being able to find anyone who knows it. –  Martin Wickman Mar 5 '13 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 Mar 5 '13 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. –  Erik Reppen Mar 5 '13 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
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 Jul 7 '13 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.

share|improve this answer
    
They're clearly doing more than QA. They're making decisions about tool use. –  Erik Reppen Mar 5 '13 at 14:48
    
@ErikReppen: I was a little unclear. I meant QA is what they are supposed to do. –  back2dos Mar 5 '13 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 Nov 7 '13 at 8:42

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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