The Industrial Age has had a profound impact on both education and software development — its influence continues to be felt today in both of these disciplines. It has led us to think of progress in terms of productivity over creativity. We think that our day-to-day work should be predominantly about the former. Creativity is at best a reprieve from the toil of our labour, and at worst a dangerous distraction from critical productivity targets. We’ve relegated creativity to the periphery of human activity, when in truth it lies at the heart of meaningful human progress.
I explore this idea further in a prior post: Lessons from an Education Revolutionary. That post also introduces Sir Ken Robinson (1950-2020), a thought leader in education whose posthumous influence continues to catalyze transformative change in prevailing education systems. In 1998, he led a national commission on creativity, education and the economy for the UK Government. Bringing together leading business people, scientists, artists and educators, he published The Robinson Report in May of 1999. Here is a quote from that report:
There are many misconceptions about creativity. Some people associate creative teaching with a lack of discipline in education. Others see creative ability as the preserve of a gifted few, rather than of the many; others associate it only with the arts. In our view, creativity is possible in all areas of human activity and all young people and adults have creative capacities. Developing these capacities involves a balance between teaching skills and understanding, and promoting the freedom to innovate, and take risks.
So then, what exactly is creativity? Why is it important to product development? How can it be applied effectively in that context?
Defining Creativity
The Robinson Report defines creativity as follows:
Imaginative activity fashioned so as to produce outcomes that are both original and of value.
While this definition was conceived in the context of education reform, it can be used as a means to improve the effectiveness of software product teams. Because fundamentally, these are teams that create and learn continuously. Software is created and shipped to the customer, while the team evaluates the delivered product and the applied process in feedback cycles. Essentially, a software product team is engaged in learning activities continuously as a consequence of its “raison d'être.”
Creativity’s five elements
By virtue of the Robinson Report’s definition, any creative activity must satisfy five elements. These are summarized below:
It pursues purpose: there is some intention behind the activity, whether it is to build a skill, create something of value in itself, or even to simply play.
It uses imagination: whether it is imaginal, imaginative, or imaginary, the mental experiences involved in using our imagination are a necessary co-requisite to creativity.
It is original: whether the originality is individual, relative to one’s peers, or historic, it is inevitably present in any creative activity.
It judges value: this happens when one reflects on and evaluates the output of their creative activity — were any mistakes made? How does it match with its original purpose?
It is a process: for sustained creativity, there is an interplay between two modes of thought: generative and evaluative. The creative process is essentially bouncing back and forth between generating ideas and evaluating them.
Now that we have a mental model through which to observe creativity objectively, let’s apply our understanding to some behaviours on software product teams.
Creativity on software product teams
We can think of two contexts in which software product teams engage creatively when delivering software:
Product: the team imagines an original product feature, builds and ships it to the customer, and finally evaluates its efficacy. Based on this evaluation, a new purpose is set by the team to either optimize the feature or to pivot to a new one.
Process: the team imagines the best way of working together (guided, yet unfettered by existing guidelines). They agree on their own original approach on how to work together. A few weeks later, the team evaluates this way of working during a retrospective; during this activity, they reflect on what worked and what didn’t. They also revise their purposed way of working by deciding on what old approaches to discard and what new approaches to experiment with.
The Robinson’s definition of creativity maps naturally to software product teams — both the work that these teams do, and how they do it. Consequently, a product team’s effectiveness can be interrogated through the lens of this definition.
As an example, let’s see how imagination can be applied to team retrospectives in order to improve their effectiveness.
Leveraging imagination in retrospectives
Imagination is multifaceted. In his book, Sir Ken Robinson describes three distinct mental experiences that are involved with imagination:
Imaginal: bringing to mind images drawn from real experiences, for example, your mother’s hair or what you ate for lunch yesterday.
Imaginative: bringing to mind images of things you have never experienced, such as a green dog on roller skates, or a vision of how you might spend your next vacation.
Imaginary: blending imaginative experiences with real ones, like a vivid dream, a hallucination, or the use of metaphor.
Depending on the activity, any of the above can come into play during a retrospective. Here are some of my favourite (descriptions are courtesy of retromat.org):
Mad Sad Glad (imaginal): Put up three posters labeled “mad”, “sad”, and “glad” (or 😡 , 😭 , 😄 ).1 Team members write down one event per colour-coded card, when they've felt that way. When the time is up have everyone post their cards to the appropriate posters. Cluster the cards on each poster. Ask the group for cluster names. Debrief by asking:
What's standing out? What's unexpected?
What was difficult about this task? What was fun?
What patterns do you see? What do they mean for you as a team?
Suggestions on how to continue?
Remember The Future (imaginative): Imagine you could time-travel to the end of the next iteration (or release). You learn that it was the best, most productive iteration yet! How do your future selves describe it? What do you see and hear?
Give the team a little time to imagine this state and jot down some keywords to aid their memory.
Let everyone describe their vision of a perfect iteration.
Follow up with 'What changes did we implement that resulted in such a productive and satisfying future?
Write down the answers on index cards to use in the next activity.
Sailboat (imaginary): Draw a sailboat onto a flip chart paper. Give it a strong sail as well as a heavy anchor. Add an iceberg in the back of the image. The iceberg represents obstacles they already see coming.
Team members silently write on sticky notes what propelled the team forward, what kept it in place, and what obstacles they see coming. One idea per note.
Post the stickies near the sail, anchor, and iceberg respectively. Read out each one and discuss how you can increase “sails”, cut “anchors”, and avoid “icebergs”.
Final Thoughts
As product development practitioners, do we think of our work as creative?
In the past, I’ve thought of writing code as an act of creativity. A team optimizing its process? That, I’ll admit, never seemed like a creative activity to me. When I reflect on the Robinson Report’s definition of creativity, however, I realize that everything a software product team does can be thought of as inherently creative.
If that is the case, what would happen if software product teams were entirely optimized for creativity over productivity?
This activity queries emotional states deliberately because doing so yields more effective results. Studies have shown that emotional memories are reactivated more, they are remembered better, and have more attention devoted to them.