The Design Flaw of Agile Methods

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.

4 thoughts on “The Design Flaw of Agile Methods

  1. I find it odd to disqualify a method because of the way it was created, the only thing that matters is whether it helps you get great results. And I would not call Jeff Sutherland a developer, he has a broad background in the military and medical science.

    Cockburn studies successful projects, not cool but useless developer projects. You’ll have to come with an actual *argument* to prove anything went wrong because of only a few people designing the Agile methods to convince me.

  2. Hi Machiel!

    Thank you for your comment and additional information. I didn’t know that about Jeff.

    Anyway, my “argument”, as you put it, is mostly elaborated in the earlier posts I indicated at the top of this post.

    I really like the agile methods, XP most of all, and I have used them and taught them in abt 10 years now. But I do believe that some important dimensions were left out and I think one of the reasons for this (there may be others, such as the maturity of that dimension at the time of method design) is that the method designers themselves worked (mostly) alone, with their own limitations in what they knew and believed to be true. I think this is uncontroversial to say but maybe something to learn from?

    I believe in agile techniques so much that I wish that the design of the methods, themselves, displayed clearer signs of cross-functional thinking.

    To be clear, I am not saying agile methods are crap, only that some vital dimensions were left out, e.g. how to understand users’ real needs and effect goals. These are vital since the are strongly correlated to the actual, resulting value of the development effort. And customer value is pretty important in any enterprise, wouldn’t you agree?

  3. I believe you’re right in the argument that things about how to really create customer value were left out in Scrum and XP. I’m not sure I agree that there would have been a better solution if they had included more people when creating Scrum and XP. Often I believe they left out “how to create real customer value” by purpose. It would have been too large scope. I do agree they should have said something more explicit about the ucd-methods were left out.

    By adopting Scrum, XP, LSD (not the drug right.. 😉 your cross-functional team WILL soon find out that you need methods for user-centred design to design a product that really fits the customer. And a mature organization will include uc-designers in their team to learn from.

    Also there are implicit practices in Lean and agile methods that will help you on the way forward understanding users. For example by truly adopting Go See leadership on a daily basis you can’t avoid to start to get a deep understanding of your users, have your team tried it?

  4. Hi Ulrika!

    Thank you for your insights. I agree that they probably left out these considerations intentionally. But do you think they had done this if they had had any education or training in that area? If they were passionate about making life better for users?

    To me, is boils down to this question: What could be more important than being effective, rather than just being efficient (I know you agree with me here)? If you want to describe a Lean process for software development you simply must describe principles and practices for the whole value chain, not just a part of it (which is known as sub-optimization, as you certainly know).

    I agree with you that great teams, using reflection on their value creation, will figure out that they need to complement their ways of working with UX techniques. However, not all teams are great. I think the chances for an average team would have been better if all aspects of software development had been covered to start with.

    Consequently, I think us agilists had better start getting better at this UX thing fast. That is why we at Adaptiv are determined to make this our Agile + UX year.

Comments are closed.