Hi Andy,

Haven't read it yet, but looks worth looking into.

Ciao.

A wonderful piece, full of great insights and reflective of long and deep experience.

I'm pretty sure I don't share the conclusion that the appropriate "mid-course correction" is to engage in an "insurgent war" of quality from the grassroots level.

As I see it, the mid-course correction for agile that brings the big picture into focus and provides the tools to engage all interested parties in high-quality collaboration is the infusion of lean thinking into the community. It takes nothing away from the power and effectiveness of agile for the purpose of delivering software (which is all agile was ever intended for), while adding the non-software-related elements necessary for real success.

IMO the crux of the problem is that "collaboration" implies separate work groups cooperating to achieve discrete tactical goals on an as-needed basis, and not seamless, natural, continuous unified effort in support of a common vision. It is that very separation, and not merely the level of collaboration between groups, that lies at the heart of many of the problems our community is interested in addressing.

The "insurgent war" approach (as I read it, anyway) accepts status quo assumptions about how organizations must be structured and how individual self-identify as professionals. What we need today is a different set of assumptions and a different canonical organizational structure - one that eliminates the administrative and cultural barriers between people who support any given value stream.

Ideas like "alignment" and "collaboration" stop short of an effective solution. What we need is full integration. There is no need for business application developers to belong to a different department than the one where their internal customers work. (Central IT functions are different from business application development and support. I'm talking about the latter just now.) Until that changes, they will always feel as if they are separate entities, and their collaboration will not be seamless or continuous.

I think the mid-course correction that can bring the big picture into focus and organize people around value streams rather than around their individual professional specialities is the infusion of lean thinking into the agile community. Agile, as you stated yourself, arose from the trenches of software development to solve problems of software development. It lacks the scope to bring whole organizations together. The values and principles can apply, but where are the tools and methods for that level of improvement? Lean appears to offer something of value in that area.

This seems just like rants of two decades ago that defended the need to differentiate between "analysts", "designers", and "developers".

It is counter-revolutionary to agile, because in agile every team member is expected to master all abilities, even if the ones who excel at a particular one make do most of the work at it.

The need for the interaction design process exists, but the specialist role does not.

Thanks for posting the presentation and I was interested to read Dave's comments above on Lean and Agile too.

I'm currently drafting a paper that develops ideas on the applicability of lean thinking to agile development, for academic / trade press publishing and I'd be very interested to hear further thoughts if the commenter or others interested in this area get in touch. You can get hold of me at cliff@agilebase.co.uk

Regards
Clifford Calcutt

Yes. This is better then what you were saying a couple of years ago at the Agile conference (if I remember it right). This just seems a little more refined. Or maybe I just understand it better now. :)

In working to educate people about the "craft" of interaction design. I often use the analogy of a marriage counselor. Who would you want working with your daughter or friend to help save their marriage?

It helps people begin to realize that even in the "non-technical" realm, we are not all created equal.