Agil softwarearkitektur eller ”emerging architecture” er en krævende disciplin inden for softwareudvikling.

I sin reneste agile form bør teams efterstræbe at følge ”You aren’t gonna need it” (YAGNI) som beskrevet af Kent Beck i Extreme Programming. Kongstanken er at krav er en ustabil størrelse og refaktorering er billigt. Er man i en situation hvor forretningen ikke har mulighed for at stabilisere sine krav i væsentlig grad, så bør man efterleve YAGNI og forsøge at designe softwarearkitektur sideløbende med at man bliver klogere på kravene. Det kan medføre refaktorering i koden og dette bør være accepteret af hele Scrum teamet.

Ovenstående er understøttet af det 11. princip i det agile manifest:

The best architectures, requirements, and designs emerge from self-organizing teams.

I 2002 skrev Barry Boehm følgende:

“You Aren’t Going to Need It,” XP advocates doing extra work to get rid of architectural features that do not support the system’s current version. This approach works fine whenfuture requirements are largely unpredictable.

However, in situations where future requirements are predictable, this practice not only throws away valuable architectural support for them, it also creates problems with customers who want developers to believe that their priorities and evolution requirements are worth accommodating.

Er man i en situation hvor forretningen er i stand til, i væsentlig grad, at stabilisere sine krav bør man planlægge efter dette, f.eks. med et Sprint 0 ved opstart af nyt initiativ, timeboxed spikes ved nedbrydning af epics eller tekniske PBI’er til oprydning af teknisk gæld.

Uanset hvilken situation man står i, så er det essentielt at huske at nedbrydning af epics og stories bør gå hånd-i-hånd med identificering af softwarearkitektur og indgår f.eks. som en del af Scrum teamets Definition of Ready og/eller Definition of Done.