By treating artistic work as somehow different from other types of development work, you create a waterfall-like project pattern that suffers from BUFD (Big, Up-Front Design). This often generates scope creep, and typically reduces collaboration by exempting the creative work from standard agile practices.
The solution is often to reframe your expectations for the creative work, and to leverage the iterative development patterns to manage scope through validated learning and time boxing. This is not trivial, as it represents a significant paradigm shift for many organizations, but it’s essential to avoid the trap of “design siloes” or “artistic ghettos” that can derail the rest of the project plan when improperly decoupled.
Artistic/Creative Work Should be Iterative & Incremental
Part of the challenge here is how you’re conceiving of the work. You’re putting “artistic” work into a different conceptual bucket than other types of work, and so are losing out on the collaborative and iterative aspects of development.
While artistic endeavors are certainly more subjective than other types of work, your goals for such work should still include:
- Making art/design part of a thin, vertical slice of functionality instead of a standalone deliverable.
- Thinking in collaborative terms, rather than as a ping-ping between a single task-performer and a task-approver.
- Following INVEST criteria as closely as possible, especially by taking a test-first approach to UI and graphics design.
- Ensuring the work is iterative by respecting Sprint boundaries, limiting scope, and treating adjustments, changes, and rework as new work to be scheduled for a future Sprint.
Some people find it hard to think of creative endeavors as testable. While it can be hard to design executable tests for non-software or non-UI visual elements, it’s not impossible. Pragmatically, what you’re really after is getting the team and the stakeholders to think about the acceptance criteria first, and for everyone to treat work that meets the Definition of Done as complete for the current iteration. This is a scoping challenge, not a creative one! Anything that isn’t part of the agreed-upon Definition of Done, or that represents a change that expands the level of effort beyond the current estimate, should be treated as future work.
Scoped, Iterative Examples
It’s important to think of creative work as iterative. “Make an approved concept drawing of a car” isn’t an iterative task, but the following could be elements of a larger theme or epic:
As a body panel machinist, I want a concept drawing that I can evaluate for production line feasibility.
As a procurement officer, I want a concept drawing that I can evaluate for initial estimates of how much steel I need to order.
As a marketing specialist, I want a concept drawing I can show to our sales channels to gauge market demand for the new design.
These types of user stories provide context which can help scope the artistic work. In addition, they give you a framework for developing a Definition of Done and testable criteria for the drawings, such as having estimatable dimensions, a clearly-
defined scale, or callouts for any design elements that might require precision machining or special production processes.
Furthermore, by making the stories about validated learning (e.g. as an opportunity to review and evaluate a design, rather than a piece of work to be “approved”), you create opportunities to collaborate and refine the artistic concepts over time. If stakeholders don’t like the design, or want to make changes, that doesn’t invalidate the work that was done. Instead, it simply creates new scope for future iterations.
This type of creative work is thus built up in an incremental, iterative fashion that can be more easily estimated and more easily delivered in bite-sized chunks. By getting away from the notion of “big, upfront design” and by moving to an iterative model with just-in-time design, you allow the creative work to leverage the same agile practices that other types of development work benefit from.