An software design colleague recently asked Agile/Usability peers for direction in adopting Agile development in the interactive marketing agency where he design interaction for RIAs.

(Actually, his said he intended "adapt" Agile, not adopt it. Just a typo? They are profoundly different, divergent intentions.)

He was asking for resources. I find that specific implementation advice or references alone are not enough to create first steps toward successful adoption. I do like to offer something helpful to peers who are motivated enough to seek assistance, and gutsy enough to take their problems to colleagues.

So instead of providing a few book titles or giving tips about running meetings or making charts, I posed two questions for him (and his team) to consider as he sought to understand Agile. I intend that considering these questions would provide a frame for his growing understanding. After all, Agile requires a rigorous commitment - and can be so disruptive to established ways. (He said that he considered waterfall "ideal" - but not why.) My point here is that Agile adoption is about more than new practices that are interchangable with current one's, though Agile is at its heart a "way of practice". My point in founded on recognition that Agile demands of an organization and its people radically different definitions of the reasons behind our practices. So if this designer or his agency starts down a path of the Agile Way, adopting of practices, is he willing to discard (probably painfully) his ideas about work and replace them (again painfully) with contrary ideas? Is he willing to cut himself (and the team) loose from the protection of a deterministic view (of software development) and in its place embrace a view which can't know what the outcome of work will be?

The Agile way is one of ongoing transformation of products, oneself and the business. The Agile way supercedes the concept of "business as usual" with the concept of "business as necessary for sustained acheivement of [healthy, humane business] goals."

Ultimately the Agile/XP/Scrum approach to developing software would change his/one's organization, its roles, performance measures, how it determines value, staff relationships, perhaps even the meaning of "managing" and the compensation structure. Certainly (in his agency) the role of IxD would be changed, perhaps even replaced (depending on how his agency responds to Agile's demands).

While one can "adapt the Agile model" and "bolt on" to existing methods, structures and culture specific agile practices, that would not yield much sustained potential value, nor harness its fundamental potential.

I find these questions help people grasp Agile's purpose and power as they begin to investigate its application in their circumstances:
How deeply would my organization (whether the team, project, business unit, enterprise or leadership) and each person in the organization be willing to change their definitions of our work and our goals?
How willing are we (jointly and individually) to approach our business goals if we know we will achieve the results we need and yet can't know before we start (nor before we're done) our final product, our specific contributions or the subsequent path our business will need to take?