可惜，許多團隊把「大局」上的技術技能看作一種不必要的邪惡，而不是重要的補充，可能是因為他們過去深受大型預先設計之害。有些人也過於渴望「敏捷」，以至於忽略軟件開發流程的其他方面。接踵而至的是混亂而非自組織，這樣的團隊也面臨著需要更直接的領導方式的挑戰。畢竟，他們在努力變得敏捷。單個點負責項目的技術層面，也跟他們對敏捷團隊的想像相衝突。這種衝突使人認為敏捷和架構是對立的：你只能擁有其中一個。與敏捷對立的不是架構，而是大型預先設計。
敏捷軟件項目仍然需要架構，因為那些圍繞複雜非功能需求和約束的棘手問題不會消失，只是對架構角色的執行不同。
集體代碼所有制，每個人都要能在架構的層次上工作，因此每個人某種程度上都是架構師。還不是自組織階段的團隊如果試圖跑太快，就會陷入掙扎。儘管人們的願望是變得敏捷，集體代碼所有制和架構角色的分配都有可能阻礙混亂的團隊，而不是幫助他們。混亂的團隊需要更直接的領導方式，單個點負責軟件項目的技術層面，將使他們受益。換句話說，他們會受益於一個人負責軟件架構的角色。理想的話，這個人會指導別人，讓他們也能以這個角色產生幫助。
軟件架構師要一個還是多個？一個人承擔責任還是團隊共同分擔？不論敏捷與否，軟件架構的角色都是存在的。只有所處語境會告訴你正確的答案。