I’ve brought in a Technical Architect to evaluate the state of code and skill maturity for my teams. They then construct an architectural guideline for the teams. I embed them with the team that has the lowest technical maturity to start as a quasi-QA role doing code review. Our definition of done requires that code pass the code review of the TA.

For a couple of sprints there is a lot of back and forth between the developers and the TA as they learn the skills and expectations to pass a review on the first go. After that, I can extract the TA on to another team, leaving the strongest technical team member to perform the code reviews according to the architecture guide.

In addition, I also work on automating check in policies on source code that look for as many architectural violations as possible. If the tools can stop the behavior before check in it cuts way down on the amount of review needed from the TA or Tech Lead.

I respectfully suggest that the root cause of the problem you are highlighting is a failure of technical leadership, not an inherent problem with having people work as self-organizing teams.

It doesn’t have to happen, but it does happen quite often.

Great points. I agree. I think Agile is the right step forward, but it is still not the best solution. We are moving in the right direction, but we still must recognize the flaws with its approach.

Good points. I think what your saying works well so long as you have mostly senior people. It really depends on the environment. Not every organization ends up hiring all rockstar developers. In that case the mob architecture problem are more pervasive.

I definitely agree with you about learning to influence without authority. That is very important, and I am not advocating not practicing that skill.

Sometimes, there has to be a final word though. And sometimes, it needs to come from the expert.

Thanks for your comment, I appreciate your input.

Establish a small team that explores scenarios and construct solutions, sometimes in sets to explore varius solutions for the problem (spikes), for the most architecturally significant stories. This stories prioritized by how probable the problem would be, and how much risk it will bring if not understood at the beginning, and how valuable to the end user or other stakeholders this will be.

This teams delivers the first version of the product with all this architectural problems explored and solutions implemented, and leasons learned about architecture, and architectural decitions already embedded in the product.

The architecture starts to emerge from the implementation of those stories, that bring some needs that the architecture have to support, and from the constant refactoring of that code to allow to acomodate concurrent and sometimes confllicting architectural needs.

I like to express some architectural constrains in tests or aspecs, that run in our continous integration cycle, giving us much more easily followed rules and conventions, depending the language is possible to create aspects the allow us to check if the code produced breaks some of the architectural constraints that we have in place.

After that you can scale with other teams that will continue to evolve the product within the architectural decitions that are embeded on the code.
Architecture is much more easy to follow when there are running examples that shows how things work.

This is how Eclipse worked, and i think it has a very nice architecture, they really used a much

The problem I see normally is that people that in traditional enviroment had gained a little more power, don’t know how to influence without authority, and miss old times when they had the final word on matters.

When in a team enviroment, the everybody opinions is equal means to influence people from a non power position, and most ideias people don’t buy they won’t follow with authority anyway or create “undesired” messes.

Architectural work will never be the same after crossfunctional teams.

Hope that this view could help you understand how architecture would mix with other activities in simultaneus engenniering world.

Cheers,
Juan.

It appears you are also setting up a strawman argument that Scrum teams do not have specializations or that all decisions are made by consensus. That is not true – specialization is allowed in Scrum, but people are not asked to focus on it singularly. The idea is your specialists bring up the skills of the lesser members, not pull down their concepts.

Frankly, if a design cannot be explained to other software professionals with a mediocre amount of experience, it is too complex, too cut and too esoteric to maintain. Please keep in mind, I am not saying it has to be explained in five minutes via a powerpoint. If after a good two hours your developers still don’t get the design and understand the tradeoffs, then you have some piss poor software engineers and a design that inappropriate for the people who are going to maintain it.