Who should be the architect in an agile project?

Question

We are developing the agile way for a few months now and I have some troubles understanding the agile manifesto as interpreted by my colleagues. The project we are developing is a framework for future projects and will be reused many times in the next years.

Code is only written to fulfill the needs of the current user story. The product owner tells us what to do, but not how to do it. What would be right, in my opinion, because he is not implicitly a programmer. The project advanced and in my eyes it messed up a little bit. After I recognized an assembly that was responsible for 3 concerns (IoC-Container, communication layer and project internal things), I tried to address this to my colleagues. They answered that this would be the result of applying YAGNI, because know one told them to respect that functionalities have to be split up in different assemblies for further use.

In my opinion no one has to tell us that we should respect the Separation of Concerns principle. On the other side, they mentioned to prefer YAGNI over SoC because it is less effort to implement and therefore faster and cheaper. We had changing requirements a lot at the beginning of the project and ended up in endless refactoring sessions, because to much has to be adapted.

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

Answer 1

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

Delay architectural decisions until as late as possible (but no later). You are going to know more about the problem in the future than you do right now, and thereby likely come up with smarter decisions.

For instance, imagine you are trying to decide up front whether to use MongoDB, some other NoSQL or traditional SQL for a project. Delay the decision: write a simple repository layer that will simply save the data in memory, or save data to a JSON file for now, and continue on. Eventually you'll have to replace this stub with something - but later on, you might know with more of a certainty which way to go: "hey, all of this really is a great fit for a document store" or "you know, SQL transactions would really help".

Its important to do this in conjunction with the concept of prioritizing the riskiest parts of your application to be developed first - that is, the parts you understand the least you should do before you do other work. This should mean you end up with an architecture that fits your solution, instead of forcing your solution later to fit in to your pre-selected architecture.

I don't mean to suggest that every project start with an exhaustive comparison of every possible web framework, storage technology, and so on. Hopefully in most projects you can simply default to reliable frameworks that have been used in the past under guidance from the team architect. I'm suggesting that this technique of delaying architectural decisions should be used when you are faced with a decision to which you don't know the answer.

One way to look at it - in an Agile project, you're always doing architecture, instead of trying to do the architecture "up front". If a pair of programmers (you are pair programming right?) picks up a story and realizes that it requires an architectural discussion, they should have it. If they feel they should involve more devs, then they should do that. If this results in a desire to remove some technical debt caused by previous lack of architecture or previous poor architectural decisions, what we've done is had the devs write up a work item for this and work with the product owner to schedule it in. Generally, explaining it in terms of ROI: "we believe the removal of this technical debt will result in the following return", generally in terms of faster response times, or shorter future development cycles.

Also, as a commenter pointed out:

The project we are developing is a framework for future projects and will be reused many times in the next years.

This does not sound agile at all. Are you sure your business requirements demand this sort of thing? Agile is all about recognizing that change happens - this week's great idea is next week's "bottom of the backlog". What technique in future prediction is leading you to be certain about what things will be important to you in three months, much less 'the next few years'?

As far as the original question "who should be the architect in an agile project", I've always selected the most experienced programmer on the team or the programmer that knows the code base the best, and given them the architect title. Sometimes the architect is just letting the developers come up with a solution and guiding the process a little bit, sometimes they are making the call. In teams organized this way, the architect is contributing code to the project most of the time, and playing the "architect" role whenever required.

Answer 2

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

Both.

It would have been better if someone realized that by slapping in another responsibility that the resultant class would be bad. Agile doesn't mean no design, it just means design (well) for what you need. You'll always need a maintainable codebase if you're making a framework for future products.

That said, mistakes will be made. Requirements will change out from under you so something that used to be a good design is no longer so. Then you need to be dilligent in refactoring, or at the very least documenting that technical debt to be prioritized for later sprints.

Answer 3

You're asking fairly broad-brush stroke questions with a minimal amount of context. That will affect the quality of answers you'll get.

If you discovered a problem that violated SoC within a few sprints after it's creation, then YAGNI doesn't quite cut it as an excuse. That's more to effect of "deliver anything" rather than deliver a maintainable solution.

The product owner should be providing enough long-term vision so the development team as a whole can make the correct design decisions. If the long-term vision isn't there, then a broader level conversation needs to be had so everyone knows problems like this will creep up again. Keep in mind that you don't have to keep hammering on that issue. Note it, make sure the consequences were understood, and get back to coding. The next time that type of a problem creeps up, point out that this was noted a while back, deal with the schedule disruption, and get back to coding.

If the product owner isn't able to communicate that vision, then it's worthwhile to have a few key members of the team spend more time with the product owner so the team can get a better understanding of what's coming next.

Honestly, this sounds like more of a communication issue as opposed to a development methodology issue.