What’s Missing from Agile?

I don’t believe agile methods is the final or complete answer on how to do software development. There are no such creatures as magical user stories. And just dropping your application on a server, no matter how automated or efficiently, does not conjure business value. No, I believe there is definitely something missing in this picture.

Agile Is Not the Final Answer

Agile methods are in many ways leaps ahead from what we had before. For many teams, becoming more agile equals improving in both internal efficiency and customer satisfaction. Still, they do appear a bit, shall we say, one-dimensional to me now, with some ten years of experience. This bothers me. It makes me go all techie and just… fix it! So here is one attempt.

The agile methods are small. Agile experts will tell you that this is by design (I do this myself). They are supposed to just be about software development. Everything else may be important but is out of scope. Well, excuse me! I thought being agile was about making software relevant again? About producing great value for clients in a quality way that humans enjoy?  Actually, it is. It’s not just software development. We have to focus on what’s important, not just navel-gaze and sub-optimise our internal processes. We need to start addressing the real issues if we are ever going to be effective – not just efficient.

Here are two things that are missing: Agile methods neither help us understand our users’ needs, nor help us realise the value at the other end. There are gaps at both ends of the value stream. (If you don’t understand what I’m talking about, read my earlier posts, “Magical User Stories” and “Only Usage Can Create Value”) So, maybe we should dare venture into some new territory? Glance a little bit to the sides? Maybe it’s about time to move away from this “from story to server” sub-optimisation nonsense into, well, how about: “from user need to user value“?

I believe we need this. Agile methods are great, but I think we must wake up and realise that they aren’t flawless.

Nobody Knows the Value I’ve Seen

Here’s the thing, in software the horrible truth is that nobody really knows what is needed. Nobody knows! You could ask your average business person but they won’t know. They may sound like they do, some actually believe that they do, but they don’t. You could ask some busy manager, but he will tell you to “just effing do it”. You may ask you local solution architect and he will say that if you just follow the information model you’ll be fine. Duh! Or why don’t you confront your business architect? They should probably have a clue about the business processes involved. However, since they don’t actually do the work, neither business operations nor software development, they have a blurry, satellite image of it all. Of course, you could ask the users (that’s a novel idea!), but the sad truth is that they won’t know either. They know some of the work in exquisite detail, but lack the overview and the technical savvy to know what could be done.

The fact that nobody really knows is what makes software development an adventure, a learning experience. That’s why I love it. How many can truly say that going to work is a little bit of an adventure? But to take part of an adventure in a safe and meaningful manner, we need a guide.

Give Me My User Guide

Who should help us close the gap to the users? Do we need to educate a whole new breed of software architects (as if there weren’t enough already)? No need. There are already professionals out there that know this. They know how to work with and talk to users, ignore the irrelevant and deduce the need. Who are these magicians? They are called user experience (UX) specialists or use-centred design (UCD) specialists. I believe that the UX specialists are our best chance of actually start realising our potential.

Don’t get me wrong. I am not talking about interaction design (although that is valuable). I am not even talking about usability (although that is a great attribute in a product). No, this is not an attribute of a system. I am talking about probing what the user feels when they use our software; connecting with the deep, perhaps unknown, needs of users to the development of great software. Putting ourselves in their shoes, not necessarily listening to what they say but observing what they do. Create experiments and use our imagination to invent a solution to what they didn’t know they needed. A guide to the users, a real, live user guide, if you will. A guide to a safe and meaningful adventure.

This Is a Plea, From My Heart to You

Please, start putting the users first. That is the only place you will understand actual need and the only place where business value is realised.

I think one really good way of doing this is to put the voice of the users at the steering wheel. Why not turn your UX specialist into a product owner – or at least a prominent member of the product owner team? They are used to thinking about user value so why not?

Of course, collaborate as a team, digging into all these target groups, needs, and examples. Let you user guide lead you but involve all specialities. By all means, keep releasing often and improve your solution iteratively. This will allow you to measure effect on real users. Just make sure you involve real users in any way you can. Close that gap! That way your chances of producing something of real value will multiply.

6 thoughts on “What’s Missing from Agile?

    • Hi Herbjörn! Sure, we need more perspectives. However, the user perspective is most often forgotten, which is why I felt I needed to write this post. We have to start from and end with the users and the value we want to achieve.

  1. Nice post,

    I wholeheartedly agree. I recently participated to UXCon just to start bridging the gap separating software development from creating valuable products, and got some interesting insights. And then I read this, and felt like “yeah… that’s it!”

    It’s so easy to start adopting a “splitting user stories” approach and then count the story points implemented, while completely losing the focus on the whole picture. What the user needs – be it the product or a service – is something bigger than the software product itself. Developing a perfect software doesn’t guarantee you’re doing the right thing.

    Doing the right thing however, can only be achieved in a learning-friendly environment, where you can be free to be (temporarily) wrong.

    • Hi ziobrando! Thank you for your friendly comment! Good observation on the learning-part. I agree, we must view software development as a learning process. To continue this thought, I think we need to balance attempts at foreseeing what the “right” thing is, with feedback on how “right” we are at the moment. Agile has been all about the latter, which feels unbalanced to me. UX can help us agile people both get better at guessing user needs and validating how that need is fulfilled. Continuously, of course.

  2. You’re right about the UX people. The moments when I’ve had the opportunity to work with a professional high level UX person, my mind has truly opened. They ask the right questions, have the background to know how to interpret communication, how to innovate and how to look beyond the users first responses.

    Often with a background in psychology, arts, communication and some technical subjects, they are truly an underestimated competence in our teams.

    I also believe there are actually some business and information architechts with similar background that can do almost the same job, with the right encouragement, maybe some complementary training in UX techniques, and option of putting all their energy in one (or at least not too many) products. I’ve seen them.

    What about all the technical people that also urges to deliver customer value? Wouldn’t it be possible for some of them with the right engagement to be able to learn to do this, while waiting on more availabiltiy and acceptance of UX-people in every development team?
    I don’t know.

  3. Pingback: The Design Flaw of Agile Methods « Den bloggande terriern

Comments are closed.