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.