How can architects work with self-organizing Scrum teams?

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?

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.

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.” )

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.

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.

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.

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.

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.

Filed under: softwareengineering - @ 17:25

Thẻ: agile, architect, scrum, teamwork

Thiết kế website giá rẻ

Danh mục

How can architects work with self-organizing Scrum teams?