In a few posts now (Magical User Stories, Only Usage Can Create Value, and What’s Missing from Agile) I have tried to make the point that, although agile methods are great (and basically grant me my livelihood), they are not infallible and certainly not without their weak points. To me, one blind spot is the ignorance of and exclusion of use-centered design (UCD)/user experience design (UX), i.e. the processes and tools for experimenting, deducing, and refining what is really important and valuable connected to the results (the effects) we wish to achieve.
This is more of a side note to this discussion, but it may be interesting to think about how this happened and learn from it. I find the whole thing quite strange. Here we have all these software development experts, even Lean experts, trying to think deeply about customer value and complete value chains, and still they fail to understand and describe a full process from user needs to user value. Why? I must admit I have no definitive answer, of course, but I think I have an idea on how this happened.
As you may be aware of, agile methods advocate a “whole team” approach to software design. The reasoning behind this is that more perspectives, experience and knowledge yield a better result for complex, creative work. It is extremely difficult for one person to be an expert in all aspects of a given field, given that this field is adequately large.
Since so much of software development is really design, from architecture to code to test to documents, I would submit that software development as a whole is complex and, to a large part, challenging and creative work. Furthermore, if doing some work is complex and creative then deciding on how to best accomplish the goals of that work is also very difficult. Consequently, to design methods and processes for software development must certainly be a complex and creative problem as well. Thinking about all the different software development methods we have designed and used over the years I think you’ll agree that this problem is one not easily solved. Working out a way of working (a method) is evidently also a form of design. It is simply the work of work design.
Now, think back on how the agile methods came about. XP was basically one man’s rebellion against the document-frenzy, project-plan dictatorship and perceived discipline of the day (Kent Beck on the C3 project). Scrum was one man’s inspiration from reading a revolutionary article in Harvard Business Review and combining this with his knowledge, wit and experience. (As I understand it, Jeff Sutherland came up with most of it, Ken Schwaber added to it and popularised it.) Crystal consists of one man’s conclusions after years of studying what really worked in software teams (Alistair Cockburn). Do you see the pattern? Always, one perspective.
Here’s the rub, I guess:
Paradoxically, the agile methods themselves were not designed by cross-functional teams.
Agile methods were designed by one or two software developers for, mostly, other software developers. Their intentions were admirable and their knowledge and experience vast, but still, in some ways, limited. And designs that have been dominated by one person always display similar weaknesses as that person.
To move forward, I think we have to try and see these flaws clearly and seek to rectify them. To be successful, Agile and Lean have to keep evolving by better utilization of cross-functional thinking. Thereby, not diluting it but making it stronger.