It’s an impediment
PSA stands for Project Start Architecture and is part of DYA®. PSA documents are one of the most written documents by architects in Netherlands. The purpose of a PSA document is to connect “architectural thinking” with organizational changes. In less vague words: It makes sure that a project gets fences by stating principles, solution direction, guidelines and some decisions before the project starts. At the same time, it’s not “solution architecture”.
Still confusing? Well, it gets even worse. It describes also any or all of the following:
- It makes sure that complete life cycle is taking care of by stating operational and flexibility requirements
- It makes sure you talk less to people in other teams, because most things are already written down.
- It makes sure you don’t discuss standards, guidelines and standard solutions, because that’s already done before the project starts.
- Even the means to achieve the project goal are taking care of.
- Actually, most of the choice are already made and written down in PSA.
Everything in this way of thinking is based on mindset that an Agile team should be kept on leash because otherwise chaos will emerge and an Agile team strives some other goal different from enterprise goals. I’ll elaborate more on this in the following posts.
But, what do I replace PSA with?
|Source: Alistair Cockburn|
When a Scrum team gets assignment, it will usually start iteration zero. In this iteration, the team talks to stakeholders, architects, domain experts, users and other teams, mostly by means of workshops (e.g. Product Vision Box). First and foremost, to understand functional and technical domain well enough in order to:
- make only the necessary, costly to change architectural decisions, needed to start with first stories. E.g. programming language, user interface technology, dependencies on other systems.
- know there are guidelines, dependencies, strategic goals and so on. The team will feel the responsibility to bring those back later on once they are affected by the user stories.
- encourage discussion about correctness and validity of corporate standards, guidelines and choices.