Agile: Turning developers into humanists

Photo by NESA by Makers on Unsplash

Jimmy Leach, who works on communications at *aio on how the Agile approach is about more than how you organise the work.

I’m not a developer. Nor a product manager. But I’ve noticed something since I’ve been hanging around with *aio. And it’s to do with the way they tackle the sort of

Any product manager who has earned their stripes will recognise the problem.

The almost old-school tradition is that, at some point in almost every digital project, the process takes over. Developers are not working to produce a better product, they are simply working to a timetable. The issue becomes about delivery — hitting dates, hitting budgets, avoiding the internal politics, getting the project online, into the apps store, wherever.

What works is what’s right. And when it’s finished, it’s done.

And, in doing so, the owner of the project completely misses the point. It isn’t only about the delivery date, the budget, or even the the customers. It’s whether it does the job — whether it satisfies the needs of the user.

And even then, that’s not quite right — the word ‘user’ has always suggested to me the idea of someone ‘practised’ in the ways of the web, a veteran of the app economy. If we do this right, we’re not designing for users, for ‘trained’ consumers. We’re designing for people. Those who need a service — in our case expense management processes.

Which is where Agile comes in. Beloved of our bearded brethren, stretching from Portland to Shoreditch, it’s modishness shouldn’t blind you to the fact that it’s the only genuinely humanist approach to technology, putting people at the centre of what developers and their teams build.

The Agile approach to digital products presumes that the product’s requirements will change, and builds the flexibility into the process to embrace that change. It builds a minimum viable product as early as possible into the journey, and from then on, it’s about adding improvement and value.

Agile is not just iterative — repeating a process til the sharp edges get knocked off. It’s also incremental. Each of those iterations should add value. Sometimes that value is in what the team has learned, rather than value to the product, but the whole Agile process should be one of progress, and progress to the benefit of those who will use it.

And that’s how we build both product and service at *aio. We build it and we improve it. Always. That’s bit never stops. Agile is exhausting, but, more importantly, exhaustive.

One measure of the agility of a project is how early in the project you could simply walk away and leave something viable in your wake. If you can’t do that til near the end, then you aren’t agile. Building early and the use of short iteration periods allows for the early release of code or beta versions into the market to be tested by humans/users. Those humans feedback, often simply through their user journeys, and that information is fed into the next iteration.

And, again, it is humans, not users, I’m thinking of. Humans may not be the users you want, but they are the users you’ve got. They may not react to your app or choose the journey through your website that you wish. But that is your problem, not theirs. It is you who has to adapt, not them. Because they are important, not you. For every Steve Jobs creating a market, there are millions of developers and product managers, however talented, who are reacting to the market, and the humans in it.

It’s that centrality of the human that interests. Agile as humanist — putting people at the centre of the process, not at the end, where they just learn of a product when it hits the market. It’s almost an ethical stance — to allow people to dictate what happens (bottom-up), than dictate to them. It doesn’t work for everyone (you can’t see Apple adopting it any time soon), but if you want to solve a digital problem, then putting the humans at the centre of it is your very first step.