Do Agile teams need PSA documents? Well, no!

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.
You can read it here: White Paper: Project Start Architectuur (dutch). There is even an “Agile Architectuur” white paper written by the same company stating stuff like “PSA Scrum team” which is ridiculous considering they deliver a document which cripples the team and its creative freedom.
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.
PSA documents are one of the common impediments solved by putting them away and pushing team members to talk to others and think for themselves, instead of pointing at some document. Until they realize that everything document describes is better understood by talking to people or more often not even in line with changing reality. Let’s not forget that any document is just a mean to communicate with each other. It has no direct value.
The worst thing of all is that whole purpose of this document is to prevent teams to think outside the boundaries of their assignment.
Anyone who uses PSA documents does not use them as defined or does not understand Agile and Scrum.

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.
An Agile team will usually put some of this stuff on Wiki or improve corporate architecture Wiki, but most should be in heads of each team member. If it is too much to remember, than you probably have discussed too much stuff too soon.

13 thoughts on “Do Agile teams need PSA documents? Well, no!

  1. So the PSA is useful, but the problems this document is intended to solve should not all be solved before starting the project but during the project when you have more knowledge and the means to experiment?

  2. So a PSA has the wrong format (a document) and the wrong scope (irrelevant information). I agree. But i still would argue in favour of architecture on an organizational level. The thing is that investments on an organization level should often be reused by business projects. To deliver this information to projects in an effective and usable form is what i would like to call Agile (enterprise) architecture. Of course this can be done by the projectteam itself … that depends on the context. But i would prefer that the projectteam can start with a focus on the projectscope and still is able to integrate into existing infrastructure.

  3. You are right. "Architecting" on organizational level is still very much important. Delivering this information to teams is of course crucial. Different teams and people interacting is even more important in order to make sure you don't get infrastructure mess.We do lack or even crave for information flow / feedback from teams who actually deal with real architecture. PSA documents are obstructing this.What we really must change is the way "enterprise architecture" stuff is being done by starting that there is no such thing as (Agile or not) enterprise architecture; defined and guarded by enterprise architects. As far as we can talk about architecture on enterprise level, it is the actual real life complex landscape of IT systems connecting with each other and delivering business value. Any other stuff is just different kind of domain knowledge and long term vision. It has nothing to do with architecture. IT systems landscape is too organic to control it by predefined architecture. Anyone trying that is just obstructing delivery of business value. Also, any enterprise architecture definition is oversimplification of the reality. I'll explain this better in the coming posts.

  4. A quote of mine is: "Creativity flourishes on a solid base of routine." To get routine, we need structure and repeating processes. Isn't EA providing this structure? And yes, this structure is changing and yes … it is just a small part of the (life)story of a teammember, but we need structure. I see it as a battle between the network structure of information and the lineair structure of information of individual people. The first is a mean, the latter is the end.Johan Theunissen

  5. What complete nonsense. Stating that an agile project does not need any restrictions at all is very strange. That amounts to advocating for an enterprise to execute completely autonomous projects. That is exactly what has led to the fragmented, overly complex and non-agile IT landscapes must organisations suffer from. The agile PSA provides as much autonomy to the project as possible and only limits this where this could hurt higher level interests. This is discussed with stakeholders of the project and stakeholders of the overall IT landscape and the results are agreements on the boundaries. Can be done in a single workshop. The enterprise architect is expert on the potential risks for the overall IT landscape and facilitates discussion among stakeholders, the resulting agreements for the PSA. If there are no risks at all then the PSA is empty. In practise this is never the case. It seems very hard to disagree with as the only alternative is to always have completely autonomous projects which is clearly utter nonsens.

  6. Ah, anonymous, I don't think I'm saying that agile does not need restrictions and certainly not that they operate autonomously . Actually Agile projects have much more restrictions in order to maintain or improve overall quality. These are (re)defined continuously by the teams and teams use the input from experts (which is a much better word than 'enterprise architect' and forces a person to actually be an expert) and collaborate a lot all the time with many stakeholders and not via some very limited and inflexible document.What you call "higher interests" and I guess lower interests is incorrect. Each team has the highest possible interest. The usual reason why a team would have limited interests is because of a document like PSA.I would love to elaborate more on this if you could provide your name.

  7. You have a wonderful post. Actually, Agile projects have much more restrictions in order to maintain or improve overall quality. I observe the efficiency of agile project management with scrum but without power, they have a very limited capability to make sure the execute is done on efforts and with the necessary quality.Here are some good for my mind casts about scrum: http://bit.ly/1TmSUlo

  8. anonymous says:

    Jeeeezzzz Viktor, very very short sighted, amateurish and blind. If you really think agile/scrum is the ultimate holy paradigm you are beyond saving. Just like any hype it has its good points, but is not a cure-all. It is OK to make a living by following hypes, but please don’t put yourself on a self-build pedestal, that is very irritating!

  9. Anonymous, any concrete example of what I said that supports your judgement? I don’t recognize any of it.
    Providing your name would be also nice.

  10. A PSA, or any imposed architecture, should be as small as possible. Such architecture documents limit the creative freedom of others and this should only be done for very, very good reasons.

    A PSA is usually created by a few people at the worst possible time: before a project starts. This is a moment where we have not had the chance to learn anything because we have not done anything yet. Architects should recognize that and be humble about it and not make tons of decisions beforehand, especially without consulting the team that will realise the product.

    The tone of voice in many PSA’s is interesting. Often, they are full of ‘demands’ and ‘rules’ and ‘laws’. “Thou shalt this and that!” It comes across as rather arrogant and not very helpful at all. Architecture is about solving problems and making trade-offs, it’s not about creating more problems that can only be solved in an Esscher drawing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s