Every day I battle, in some way, with the question @johncutlefish raises here: Is Agile the enemy of good design?
This article raises some valid points. I've also got some thinking.
Thread:
This article raises some valid points. I've also got some thinking.
Thread:
I've worked in environments where we've done big, upfront design that has been "chucked over the wall" to development.
This approach has it's up, and it's downsides.
This approach has it's up, and it's downsides.
I've worked in environments where we've done big, upfront design that (with the cross-functional team) we've sliced into releases and then iteratively delivered.
This approach has it's up, and it's downsides.
This approach has it's up, and it's downsides.
I've worked in environments where we've done small, story level bits of design pretty much at the same time as somebody writes the code and then we "ship it".
This approach has it's up, and it's downsides.
This approach has it's up, and it's downsides.
When we argue for and against these different approaches, an observation I've made is that we consider all design equal when doing so.
Here's the thing though, the problems we solve differ in size (complexity, existing knowledge, constraints etc.).
For example:
Here's the thing though, the problems we solve differ in size (complexity, existing knowledge, constraints etc.).
For example:
Scenario 1: Attempting to remove a small amount of frustration for a user in a checkout form, could be done side-by-side with a developer with nothing but conversation, sketching and coding.
Scenario 2: Working out how to integrate a new proposition into your existing application, that might take many workshops and meetings to build a shared understanding, various methods of research to learn different things, information architecture work, heavy visual design etc.
In both of these scenarios, we're doing design. But what I believe we forget in this conversation is the differing complexity; that one scenario may have taken an hour, the other could take months.
Not all the problems we solve are equal.
Not all the problems we solve are equal.
At this point, I remind myself that the Agile manifesto does not mention or enforce a specific process. In fact, at its simplest, Agile (with a capital A) is a set of values and principles.
Principle #1 of the manifesto is: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Can anyone disagree with this as a principle?
Can anyone disagree with this as a principle?
Folks shout from the rooftops to put the customer first, this is principle #1 of what I've heard people describe as a "software developers thing".
Yes, Agile was created by software engineers but that isn't a reason to dismiss the principles behind it. They're solid.
Yes, Agile was created by software engineers but that isn't a reason to dismiss the principles behind it. They're solid.
John's article resonated most with my thinking when he said:
'“Good” waterfall beats abused Agile any day.'
Agile isn't the bad person here, the implementation within your context is.
'“Good” waterfall beats abused Agile any day.'
Agile isn't the bad person here, the implementation within your context is.
John's article lists two broad approaches, they'reapproaches I've tried and suggested, I still do sometimes.
There's a third approach, one I'm seeing the most success with...
There's a third approach, one I'm seeing the most success with...
The third approach means moving the conversation away from Agile (capital A) and onto agility.
We need to agree that while not all design (problems) is equal, we aim to deliver value to customers at the earliest point that provides value.
We need to agree that while not all design (problems) is equal, we aim to deliver value to customers at the earliest point that provides value.
We agree to give the problem the time it needs, although it'll often require less than we think. It's about thinking holistically or specifically if we need to.
How “far ahead” of development you work with design shouldn’t be fixed. It should be variable on the problem at hand.
With this new agile (lower case) approach to design fitting into a cross-functional team. I also want to quickly touch on the 2nd approach in this article.
I've joined @jmspool in saying that everyone is a designer. Adding to this, I've also noted that as appointed designers, it's our role to make everyone a better designer. To lead great design within our organisation.
This means upping everyone's game.
This means upping everyone's game.
Agile is not the enemy of design. A poor implementation can be though.
Understand the implementation, why it doesn't work and negotiate on fixing that. Find leaders who would benefit from an adjusted implementation, make them champions of the change. There are other methods too
Understand the implementation, why it doesn't work and negotiate on fixing that. Find leaders who would benefit from an adjusted implementation, make them champions of the change. There are other methods too
I leave every appointed designer with this question: When was the last time you asked your team the question: 'How quickly can we go from idea to a customer's hands?'
Shaking heads start as folks respond: 'That's not my concern.'.
It bloody well is, my designer friend.
Shaking heads start as folks respond: 'That's not my concern.'.
It bloody well is, my designer friend.
