TL;DR
This is an old question, but is still attracting attention more than a decade later. As such, it's worth giving it an answer updated based on 11 additional years of agile adoption in the industry.
The original question posits that agility and agile frameworks somehow obviate the need for either architectural planning or an architect's skill set within a software project. It does so by conflating command-and-control management with the practice of sending requirements "downstream" from architects to developers. One is a (badly outdated) style, while the other is a (just as badly outdated) practice.
The question also presupposes that agile frameworks that encourage cross-functional teams, tighter collaboration, and emergent design through practices like just-in-time planning and leaving design decisions until the last responsible moment are orthogonal to the practice or profession of a systems/software architect.
None of the assumptions above are true. However, the notion of what architectural design should look like and who is responsible for doing it requires frame-shifting the question. Architects and architecture still exist; in many domains, they just function better as members of modern agile teams.
Agility Isn't Orthogonal to Architecture
Agile frameworks don't discount architecture. They just usually postpone architectural decisions until the last responsible moment since the requirements may change over the life of the project. Three key principles behind the Agile Manifesto state:
- Welcome changing requirements, even late in
development.
- Simplicity—the art of maximizing the amount
of work not done—is essential.
- The best architectures, requirements, and designs
emerge from self-organizing teams.
So, the goal of agility isn't to ignore architecture or design, but rather to acknowledge that "big, upfront design" is generally waste (in the Lean sense) because requirements and designs are likely to change over the term of the project. The old adage:
Plan the work, then work the plan.
is largely at odds with any framework or methodology that embraces continuous change.
Emergent design and limiting architectural work to "just enough" for near-term planning (SAFe calls this Architectural Runway) basically converts architectural discussions into just-in-time planning within the team rather than big, upfront plans received from external sources. So while I agree that not all projects are suited to agility, I strongly disagree that properly-implemented agile frameworks and practices deprecate or delegitimize the value of architectural planning.
Autocratic Architects are Obsolete; Architectural Skills Aren't
By definition, a cross-functional team contains all the skills necessary to deliver the current increment of development. Most agile frameworks therefore have a bias towards T-shaped people rather than overly-focused roles, but that doesn't mean that teams never leverage I-shaped people for specific tasks or externalize resource dependencies.
Probably the most accurate thing to say is that in frameworks like Scrum, there are likely people on the team who are stronger in some areas than others. However, since architectural decisions often impact everyone on the team, everyone gets a voice in making near-term architectural decisions with the active collaboration of those with more knowledge of architecture.
For example, a given architecture is likely to impact testers, programmers, database administrators, network administrators, DevOps pipeline administrators, and so on. Since the paradigm is all about collaboration, any architectural decisions that don't consider the impact of those decisions on each of the team members and the areas for which they are most often responsible typically creates a lack of cohesion and a potentially non-unified increment.
So each iteration, an agile team considers what the optimum level of architectural planning should be for the next iteration or two, and makes that part of their iterative or incremental planning. They limit that planning to what is currently in scope, or likely to be in scope shortly; this prevents a great deal of wasted effort in the event that the project pivots, requirements change, or better ways of accomplishing the objective are discovered.
This Applies to UI/UX Skills, Too
Similar questions about how to integrate user interface and user experience design into agile workflows comes up often on this site. The basis of those questions are largely the same, although the questions are often more about how to integrate the people and activities rather than whether or not they have value.
If you search this site for UI/UX questions, many of the answers about how to integrate those people and skills into an agile team will apply to software architects, too. In short, they should be part of the team, should be collaborative, and should be collaborating on the current deliverable increment rather than working ahead of the rest of the team.
A Parting Caveat
There are certainly some problem domains, types of projects, and corporate cultures where agility is neither appropriate nor desirable. As examples, space missions are not well-suited to empirical design on a per-mission basis; pacemakers aren't good candidates for adaptive or incremental improvements to quality control; and large wars aren't ideal situations for just-in-time resource allocation.
Nevertheless, while any given agile framework is not universally appropriate, agility in general is now the de facto standard in many sectors precisely because it encourages adaptability, transparency, and close collaboration. Validated learning and continuous improvement are at the heart of properly-implemented agility. If you are a software or systems architect, that generally means you need to drink the agile Kool-Aid or look for the rare opportunities where agile inspect-and-adapt feedback loops aren't appropriate or valued.
