Agile is a polular buzzword-concept in good currency
- a reflexive response to the emerging credibility of UxP as a discipline
- fueled by the threat of downsizing/outsourcing from the beancounters
- an expression of the universal desire to be an artist
Patterns & best practices are useful guidelines - but they're just that. An "Interaction Design for Dummies" book would provide reinforcement for our credibility and sense of identity. Its greatest value will probably be as a consciousness-raising tool among the many UI hobbyists out there
Programming and Interaction Design are two opposite, though - hopefully - complementary perspectives on the same task.
It's always been an interesting, dynamic debate.
The Programming perspective is machine-centric and inside/out
The UX perspective is customer-centric and outside/in
I have exercised my programming skills since the 80's, but - as a UX guy - I don't consider it to be a job description for me now. I consciously opted out of that arena when I realized that dynamism = schizophrenia when you try to do everything. It is difficult - if not impossible - to wear both hats effectively.
Rules of the Game
The challenge is for these two radically different mindsets to play together gracefully. The debate hinges on "territoriality creep" between Development and Design.
The Development Perspective
Conventional IT teams tend to be programmer-centric, both in terms of philosopy and staffing.
Documentation, Process and Design (in the sense of Interaction Design and Usability) are rarely well-represented. If anything, they are often viewed as a drag on the "real" challenges of producing code quickly.
The Design Perspective
The User Experience discipline is neither well-integrated nor well-protected in the conventional IT environment.
In this situation, qualitative issues (i.e. Usability) can become a political football.
In such an environment Interaction Design is already at a profound disadvantage: The size of the team, boundaries, homefield advantage, leadership, scoring system, resources, time of play, rules & enforcement all lie with the programmers.
Did Agile Kill SDLC ?
I've heard the term "damp agile" used to describe the synthesis of waterfall and agile. Seems to me that "agile" is a code word for a more flexible, responsive waterfall-ish process rather than the absence of process altogether. I don't know that there are many successful models of either extreme. Instead, both ends (strict, confining process vs. artistic anarchy) are trying to find the most appropriate synthesis.
Documentation (whether you call it that or not) is absolutely critical to success of any team. The "formalized communication" (wiki, paper docs, whatever) is the repository of the architecture of the data (IA) as well as workflow, articulates shared assumptions, and so much more.
It's critical to internal team collaboration, product implementation and stakeholder signoff. If Agile implies "Documentation? We don't need no steenking documentation", then I just keep walkin'