Agile, Lean – It’s All About The Team

I’ve seen and heard of quite a few Agile projects that have failed to live up to expectations, or even failed completely. And I’ve watched organisations – agencies in particular – struggle to adopt Lean UX.

Not because there’s anything wrong with the methodologies, I think. And not necessarily because they were implemented badly – though I’ve seen that happen. I suspect it’s because one crucial factor gets overlooked – the people.

So much depends on the specific individuals involved in the team – not the roles, the actual people behind the titles. It’s not enough just to look at the roles, to say “We’ll resource a UX lead, an interaction designer, a front-end developer, a technical architect, and a copywriter” (or whatever). You need to go beyond that and look at the individuals themselves. Their skills, experience, strengths, weaknesses and personalities.

Effective teams are rarely thrown together at random. They take time to nurture, to get to know and understand each other, to bring out their best, for the whole to become greater than the sum of the parts. And they probably need to go through a few failures to get there.

(I think that’s probably why so many agencies, especially the larger ones, seem to struggle with Lean UX in particular – because they operate in the other sense of lean, seeking to eliminate unused resource, minimise non-billable hours, maximise their efficiency. They don’t have people sitting around twiddling their thumbs – far more likely they’ll be running around at the last minute, desperately trying to pull in freelancers to fill gaps in the resource plan. Not that there’s necessarily anything wrong with that – from a business perspective, it clearly works well for many agencies. But it’s probably not the best way to nurture truly great teams, to build that long-term shared understanding that comes from working together for more than just one project – or worse, just one small part of a project.)

The nature of the team – the specific people within it – will largely determine how closely you can follow the Lean or Agile process, how lightweight you can go on the specification, where you draw the balance between an expert-led linear process and a fully collaborative iterative one (neither extreme is ideal in my view – somewhere in the middle is the happy medium, if we can find it).

For example, in an Agile development project, the skills and experience of the developers will have a huge influence on the level of design input, specification and oversight required. Ideally you would have highly experienced developers who are good at solving design problems – they’d be more like consultants, solutions architects, or that holy grail the designer-developer (or engineer as I believe it used to be called in ye olden dayes).

But if you have more junior, less experienced developers, or those with a narrower skill set, people who need greater direction, clearer briefs, then you’re going to need a lot more design leadership – unless you just want something that ticks the boxes, provides the individual functions requested, meets the contractual obligations, but falls short of being an elegant, coherent, nice-to-use solution. A screen of widgets, rather than a considered user experience. A box of ingredients rather than the finished cake.

I firmly believe that Agile development still requires a design stage (and not just a one-or-two-week ‘sprint zero’…). Certainly as a methodology it permits more lightweight specification of the design, and it affords greater flexibility to adapt or pivot as circumstance or new insight dictates, but the product being built still needs to be designed.

Similarly Lean UX doesn’t absolve the designer of his responsibility to define, own and champion the vision for what the product should be. Yes, we should of course engage with users, as much and as often as possible. And yes, we must involve other disciplines, especially those who will be building the product. But that’s just good practise. It’s design research, it’s feasibility study, it’s recognising that the best design isn’t done in isolation. So nothing new, then.

Good design requires engaging with others. But it also requires vision and leadership. Pragmatism, diplomacy, a willingness to listen, to adapt – yes. But also the tenacity to see the vision through, to make the tough decisions, to take responsibility, to take ownership – and to not cut corners or compromise on the quality of the product for the sake of making the development easier.

The stronger the team – the better the individuals within it know each other, the more collective experience they have of working together, the more they understand each other’s strengths and weaknesses, ways of thinking, motivations and personalities – the easier it will be to share that vision and share the responsibility for realising it. The easier it will be to co-create, to work efficiently together, to come up with great ideas and to execute them well. And chances are, those ideas will be all the more creative and all the better executed as a result.

But teams that are ‘weak’ – that are inexperienced, either individually or collectively, that have not worked together before, that have been thrown together at the last-minute, or which have been selected by ticking off the desired roles rather than picking the right people… Chances are they’re going to struggle.

They’re going to need time to get to know each other, they’re going to spend time learning about each other, getting to understand each other’s thinking, approaches, quirks. Time that the project likely doesn’t have. They’re going to make assumptions about each other’s capabilities. They’ll overlook or ignore weaknesses rather than compensate for them, because they don’t want to call them out. They’ll give each other the benefit of the doubt. They’ll overestimate strengths. They’ll fight – whether consciously or sub-consciously – over who’s in charge, who has more authority, who’s more senior, who makes the final decision when there’s no consensus. They’re going to need stronger leadership and a more clearly defined vision to work against.

Agile and Lean are both great methodologies. But the risk, as I see it, is that they are all too easily misused. It’s too easy to use Agile development as an excuse to do less design up front, or none at all – “We’ll design as we build, we’ll work out the requirements as we go along.” And Lean UX can, I fear, too easily be abused as a way to cover up for a lack of design expertise, an absence of good quality UX resource – “We’ll collaborate as a team and co-create with the users” can all-too-easily mean “We haven’t got anyone to lead this”.

If you’ve got a truly great team, that knows each other, that works well together, that has the right combination of skills and experience, then great – Agile and/or Lean UX ought to work well. Go for it. And take care to nurture the team for the long term.

But if you don’t have that, then at least make sure you’ve got a damned good UX practitioner – or designer, architect, consultant, product manager, whatever you want to call them – and empower them to take ownership and responsibility for the product vision. Assuming you can find one, of course…

About Jonathan Hirsch

I've been working in the interactive media industry since 1995. I'm a problem-solver with a multi-disciplinary skill set. I work on a freelance / contract basis. I help clients create great digital products.

Leave a Reply