The Creative Process
If software development is truly a creative problem, maybe we should look for inspiration from other fields solving creative problems.
We can start with our closest neighbors, the friendly UX and design folks we work alongside. There is a lot written about design thinking and the creative process, and design shops like Zurb have been kind enough to publish the exact processes they use to design products. The steps are basically:
Ideate?—?Experiment with divergent solutions and distill them.
Test & Learn?—?Use the prototype to test, learn and improve.
How can we apply these ideas to a development process?
Developers already do some of these creative tasks, but they’re never officially part of the process and almost always under the radar. No project manager wants to hear her tech team is “ideating.” It’s seen as an emergency measure?—?like “down time” for a factory line, to use our manufacturing metaphor. If software is a creative problem, then we should build exploration into the process.
Imagine what a time-boxed development sprint modeled after the design process might look like.
It could start with bringing the development team together to identify and document key problems. Developers could then individually break out and research/test diverse solutions to those problems. Without the pressure of shipping features, they could validate new methods and patterns for solving the given problems.
In a convergence meeting, the team could share and distill the diverse ideas into consensus recommendations. Developers receive feedback from other team members who may have envisioned solutions in completely different ways. Armed with a consensus direction, the team then builds out the set of features using the patterns they’ve agreed on.
As a final step, the team should instrument and measure the work product in an objective way against success criteria like performance, organization, and complexity to inform the challenges of the next sprint.
Would this exact process actually work? It’s hard to say. The example just serves to illustrate that we don’t have to look at development purely through the rigid lens of linear, incremental construction. Even if the process we described doesn’t work as a whole, nobody can deny that it includes obviously valuable development activities that are completely overlooked today.