2020-01-02 ☼ innovation
In software development, we love our processes. Scrum, Agile, Waterfall, Extreme Programming, etc. They are all designed to allow teams to deliver software on a predictable schedule. Product managers love having a way to make and prioritize requests. Software developers like the way it prevents unrealistic expectations from forming. It provides a cadence to product development.
But can innovation truly be delivered with regular cadence? Wait! Don’t close the tab just because I used the I-word.
Innovation isn’t exclusively a world-changing device that revolutionizes society. The innovation I am describing can be a new UI detail in an element as old as the web. It’s the novel way of storing files in a project long presumed was dead.
It’s no coincidence that the designer and developer in the above examples are a business owner and researcher, respectively. Well, also because I hand-picked them to help prove my point. Nonetheless, the important part is that they were free to explore.
Sometimes spending a few days tinkering with UI may not lead to UI innovation. Working with filesystem algorithms may not produce novel storage technology. An explorer doesn’t always discover a new continent.
There are tasks that don’t require innovation. Sometimes the work really is about fixing a bug and getting it out the door. Sometimes you’ve identified an improvement and now you just have to build it. For these kinds of things, a regular shipping schedule that works for your team is essential. Keep shipping.
We must recognize, though, that these schedules will not provide innovation. Once we accept this, we can begin to think about how to layer in time for exploration. The details of how much time to allocate towards tinkering really depends on your team and goals. I have no doubt that the people who brought us these great processes will be able to hash out the details1.
Two examples we can look at are sabbaticals and 20% time. Both of these practices are designed to give employees the flexibility to explore problems with uncertain results. They have been implemented with varying degrees of success at universities, major corporations like 3M and Google, and even bootstrapped companies like Basecamp.
Find out what works for you but don’t try to force the results. The only way to discover is to search.
Rich Hickey has many of the right answers in his talk, Hammock-Driven Development (2010): ↩