Nimble Agile

Mark Boulton wrote a really helpful blog post earlier this year, 'How we work', detailing the design process at Mark Boulton Design (now part of Monotype), capturing not just what they do but also what they don’t. It chimed, as so often a really good blog post does, with a hard-to-express dissatisfaction I was feeling yet couldn’t quite put my finger on. It’s a frustration with how I often see Agile practiced.

It comes down to this: your Agile process should be designed around the skills and needs of the team and the product, not the process.

Tractor factory production up, comrades

You’d think with the mantra of self-organising teams this would be to state the most obvious thing in the world, but it isn’t. I’ve worked in teams fighting against a constraining models of overly-prescriptive user story writing, an over-focus on the value of estimation, and slavish adherence to ceremonies that did little for team process or effectiveness, but looked good on a burn down chart or a team back-slapping themselves for upping their velocity over a sprint cycle.

What does that even mean.

As little process as possible

I don’t have much truck with the concept of soi-dissant ‘agile coaches’, but if they are there to do one thing, it should be this: to look around the team they have, the skills and experiences that those people bring to that team and then determine how much process they need to help them do the job. For example,

how much experience do designers have working in an Agile context?
has this team worked together before?
how much trust is there between team members?
are they co-located or not?
how good or bad have past experiences been?
how long has this team been working together on this product?
what do we need to do to best tackle the design and development challenges in front of us right now?

If your answer is a ‘well, this is how we did it on my last project’ or your process isn't evolving over the duration of a project, then it suggests to me you aren't thinking hard enough about it.

I'm inclined to agree with my friend Matthew Solle that Agile is, as much as anything, ‘a frame of mind’. I could not go back to the old ways of workings, but I'm not inured to the deficiencies of Agile either. Like democracy, it's the worst form of governance except all those other forms that have been tried from time to time (with apologies to W Churchill). But I'd love to see it used with far more empathy towards the people it's there to support.

‘Being nimble means evolving your process so it can change as needed’
— Jason Santa Maria

18 May 2014

The right tool for the job

Another day, another ‘one true way’ blog post floating around Twitter arousing ire and retweets in equal measure. I don’t doubt the good intentions of those urging you to abandon [insert thing you do] and throw your weight behind [insert thing they do], but if I’ve learned anything over the last couple of years it’s this: I rarely work the same way twice. In the past twelve months alone, I’ve done the bulk of my design work variously in sketch, at a whiteboard, in HTML and in Illustrator. It might even include ‘in words’ too, because sometimes that's where it felt the design was truly rooted.

I’ve said in the past that one of the most difficult challenges for any freelancing designer like me is figuring out which particular designer-shaped hole you're being asked to fit into and working out where and how you need to push at the edges of that to do your best work. It’s just as true to say that so much of design comes down to identifying the best means of communicating design intent - a common language to make yourself and your ideas understood.

And that's why the way I work changes - because the people and the projects change.

A number of factors are at play here, for example: colocation or working remotely; who you’re collaborating with and how; who you’re working for; and the cadence of the design process. So, I really worry when I see some designers attach themselves so definitively to a particular app or method.

I’ve got this wrong in the past too - blithely assuming that one particularly way of working would suit a project only to discover fellow designers reaching for a distinctly different language. But when it comes together, whether by happy accident or careful trial and error, and it works, well then it’s like magic.

This is as much a note-to-self, but we need to keep our eyes open, to think hard about what the project really demands, what our fellow designers and developers need, how to best open up the design process to let our clients - whether formal or informal - in. And select our tools accordingly.

Responsive web design, if you will.

Newer posts