Design in your agile process
If you’re making software the right way, you have designers and developers working closely together to solve problems. What you may not have (yet), is a common way of working with both. Even within organizations that value the craft of design, there is a tendency to treat it as ‘different’ and employ unique methodologies for defining, estimating, tracking, and completing design work than are used for development.
As you think about how your teams are structured, pay close attention to accidental versus intentional differences in how they operate. Differing methodologies often lead to diverging motivations, default assumptions, and ideas of success. Though you may be emphasizing the importance of design and development working together, if they have different ways of operating this will introduce tension or even undermine your goals.
How, then, are design and development different? What unique characteristics do they have that would provide relevant context and constraints for a methodology aiming to incorporate both?
If we are considering both from an agile perspective, design and development are more alike than they are different. It is completely reasonable to ask a craftsperson to estimate their work, sub-divide larger efforts into smaller ones, report regular progress, demonstrate completion of efforts, have their work checked for quality, and, in effect, turn a loose description of a desired outcome and a set of explicit and implicit constraints into a tangible solution.
Because development as a discipline in a corporate environment at scale has existed longer, companies believe they understand how it is done. They also believe it to be a repeatable process, even commoditized in many cases. (Generally, I think they are wrong, but we are talking about what they believe, not what is actually true). This colors their demands and expectations. We as individuals believe that painting a house, fixing a leak, repairing a car, etc. are all repeatable processes so we think nothing of asking for estimates and expecting them to be reasonably accurate. Software development is treated the same way.
Design, however, is newer to many companies, and the stereotypical image of the people performing it is at odds with what companies expect. These people aren’t developers, they are ‘creatives’! They are artists! You can’t schedule, decompose, and incrementally achieve inspiration! These reactions are understandable (and likely something designers don’t mind), but they aren’t productive.
Design work performed by professionals, just like any other creative task (like, say, development), can be estimated based on experience, broken down, and delivered on a schedule. That’s what separates professionals from hobbyists. We all have to deal with constraints as we conjure something out of nothing, whether it’s code or comps.
It’s likely, though, that designers haven’t been asked to do these things before, so they need practice to get good at them (just like developers who have never been asked to estimate before are likely to be bad at it). That’s ok. Whether they realize it or not, they likely are already following a methodical approach to their craft, they just need to recognize it.
Having the same expectations and core way of working across disciplines keeps everyone aligned. It also builds empathy between team members. Designers recognizing the creativity involved in development and developers understanding the rigor and intentionality of design results in a stronger team that understands their common goals.