Agile, Design and Expertise Management

Design is an expertise, or expertises. Agile, as an approach to software development, is also an expertise.

Both design teams and Agile teams complain about how they are mistreated in projects and organizations.

As far as management is concerned, design and Agile are very similar victims.

The former is no less scientific than the latter, and the latter is no less creative than the former.

By the way, “Agile for design” merely doesn’t make any sense. The essence of the Agile practice is no different from that of most design practices.

What really hurts design and Agile in organizations is the stitching of an incompatible accountability system to creative practices.

Many organizations’ approach to expertise is perfectly summed up in a scene of the movie Love Actually (2003), where the US president tells the UK Prime Minister: “I’ll give you anything you ask for – as long as it’s not something I don’t wanna give.”

It’s a problem of power, not one of expertise. When expertise is not respected and, respectively, not empowered in the organization, it merely can’t live up to its reputation.

If we don’t study power, then we won’t understand why certain things happen to design or Agile or, in fact, any expertise in organizations.

For an expertise to thrive in and contribute to an organization, when/where/how it should be challenged matters a lot. Accordingly, what power the expertise represents matters a lot.

What power does Agile represent? What can it decide? When can it intervene? How does it resolve conflicts of interest, opinion or decision? The answers to those “power” questions define the scope of the practice and how useful it actually is in the organization.

The same goes for design. What power does design represent? What can a designer decide? When can they intervene? How do they resolve conflicts of interest, opinion or decision? The answers define the scope of the design practice and how useful it actually is in the organization,

And power is not the only challenge. External and largely commercial interest is also at play.

Many commercialized formulations of Agile gives organizations the wrong idea – that they can skip “thinking hard” and jump to “doing hard (and think along the way)”.

But the problem is, it’s harder than expected to think when the action is on – in that regard, commercial Agile is similar to pornography.

Commoditized “design process” and “design methods” fall unfortunately into the same pornographic category – as if you can safely stop thinking and start doing after a few steps along a linear process or methodical steps, or that you can confidently follow a recipe to make great design happen by itself, or even just the idea that there’s a recipe for every solution to every problem.

As we all know, that’s just not true.

But why do businesses (read: consultancies) sell them anyway? Because it’s easier to sell. It’d be so much harder to sell if they have to explain how expertise actually works or how organizations need to handle expertise.

To sum it up: some expertises in organizations lack the power to thrive, while their pornographic commercialization corrupt their reputation.

Perhaps it’s not hard to see why – expertises like design and Agile don’t fit well with the dominant organizational assumption on business functions, division of labour and the traditional role of expertise as a result of that division.

Expertises like UX design and Agile slip horizontally into other functions and expertises. They cross the labour’s boundaries of division. Their success sometimes demands a renegotiation of those boundaries and, accordingly, a redistribution of power in the established power structure. Those are not exactly easy things to do – at least not like some other expertises such as human resources, accounting, data analytics, physics or medicine.

There’s a gap in expertise management.

Expertises like UX design and Agile are integrative, cross-functional and interdisciplinary. They don’t work in silos with siloed power and siloed management. Organizations of today can no longer rely solely on the division of labour to let the needed expertises do what they are supposed to do. Integrative, cross-functional and interdisciplinary expertises need to be managed differently.

If the division of labour is the first revolution of expertise management, then we’re perhaps witnessing the second – expertise management 2.0, where integration and synthesis are just as (if not more) important as division and analysis.

{END}