Day 3 - Design Thinking

Written by: Ben Rockwood (@benr)
Edited by: Shaun Mouton (@sdmouton)

DevOps has many meanings and definitions, spoken and unspoken alike. I have maintained for some time now that DevOps is, above all else, a banner of change which has ushered into the world of IT a variety of ideas, new and old.

The truth of what DevOps really is can be seen in the previous paragraph when I said “ushered into the world of IT.” Once upon a time “Developers” were called “computer programmers” and “Operations” were called “Systems Administrators”, but today those formal titles seem very constricting and inaccurate. Furthermore, both programmers and administrators were both in a department called “Information Technology”, but in most modern companies IT refers only to a small sub-set of technology related activities within an organization, namely those related to servicing employee equipment and infrastructure (laptops, printers, WIFI, etc.)

It is therefore evident today that technology is an integral part of business operation in a new breed of 21st century companies, where the assembly line on a shop floor has been replaced with a continuous integration pipeline accessible to anyone operating from anywhere with internet access. The world has changed and the name ascribed to this transition from back office IT function to core business function is “DevOps”.

DevOps has helped us transition from support function to “business operations.”

Within the DevOps movement have been many so-called “thought leaders.” The function of a thought leader is to seek out and bring into the DevOps movement ideas and methods from other schools of thought. History teaches that great innovation has always come from cross-disciplinary teams working together towards a common goal. Within DevOps we’ve seen an interesting alternative form of this, wherein individuals from within Technology go out and become excited by other disciplines, learn all that they can, and bring back into the community what they have learned.

The large milestone contributions to DevOps have thus far come from the Agile software movement, from the LEAN and Operations Management (Goldratt, Deming, Ohno, Shingo, Shewhart, Taylor, etc) movements, and from Human Factors and System Safety. These three disciplines form the foundation of the body of knowledge from which DevOps draws.

To a lesser degree DevOps has drawn into it knowledge from every discipline which it has happened upon. Emotional Intelligence, Organizational Behavior, Psychology, Philosophy and Epistemology (namely, Pragmatism), Cybernetics, Neuroscience, Architecture, and countless other disciplines are often cited but rarely attributed directly in any significant way. The ideas from these disciplines are simply adopted and become lost within the developing common tapestry of DevOps ideas.

In 2015 we’ve happened upon another discipline which is starting to meld with the DevOps tapestry, that of Design Thinking.

Design Thinking, like DevOps itself, is somewhat controversial as to whether or not it is in fact something new or simply a fad. The term was coined in 1969 by Herbert Simon in his book The Sciences of the Artificial and then made famous in 1987 by Peter Rowe’s book Design Thinking. Through the 1990’s several articles and books were written which broadened the scope of Design Thinking from a way to create new things to a method of approaching complex problems. In 1991 David Kelley founded the company IDEO, an international design and consulting firm in Palo Alto, California, which has subsequently become the poster child for innovation and the applications of Design Thinking.

The rise in popularity of design thinking is due to the belief that the way to succeed in business today is by means of innovation and design. The poster children for success in the 21st century are businesses like Apple, Amazon, and Google which are now the most valuable companies in the world, and it is innovation that is believed to put them there. I say “believed” because when other businesses look at them it is “innovation” that they single out as the thing they are missing and try to emulate. The problem however is that innovation isn’t something you can simply start doing, its not so easy to copy.

Like DevOps, design thinking starts with culture. It’s more of a worldview than a process, but because it does have a process it is only natural that non-innovative companies will take it, try to implement it, and hope for the same dramatic results.

IDEO’s David Kelley and Tim Brown are all too happy to share the design thinking message with the world, and business schools have jumped on the bandwagon, especially Roger Martin, Dean of University of Toronto’s Rotman Business School, which is closely aligned with his alma mater Harvard Business School. Tim Brown wrote Change by Design in 2009. That same year, Roger Martin wrote The Design of Business. David Kelly, along with brother Tom Kelley, wrote Creative Confidence in 2013, although Tom Kelley (who also works at IDEO) wrote The Art of Innovation back in 2001, ahead of the trend.

The design thinking process is straightforward and will look familiar to anyone in the Agile or DevOps communities:

1. Empathize: Develop a deep understanding of the challenge
2. Define: Clearly Articulate the problem you want to solve
3. Ideate: Brainstorm potential solutions, Select & Develop your solution
4. Prototype: Design a prototype (or series of prototypes) to test all or part of your solution
5. Test: Engage in a continuous short-cycle innovation process to continually improve your design

The primary contribution of design thinking to the world is an emphasis on step 1 “Empathize”. This means that design thinking starts with a human centered focus and attempts to understand the problem from his or her perspective. Any problem address that doesn’t have human beings at the center is not a design focused solution. When a problem has multiple stakeholders, that is, humans who are affected differently by a single situation or problem, each of their perspectives is sought out to help arrive at a solution which addresses them all, which is a form of systems thinking.

Once a problem is understood, it is defined, typically via a “design brief”. The brief is a document which outlines the actual problem, not a proposed solution, along with context and analysis discovered in the empathize stage, so that a team can be assembled to begin the ideation process.

Ideation, Prototype, and Test form a cycle. The problem is considered, ideas are brainstormed and examined, and eventually those ideas are synthesized into one or more prototypes. Those prototypes are experiments which are created and tested. Based on those results the cycle can begin another iteration.

Several elements should sound familiar to the DevOps and Agile communities! User Stories are a way to empathize with the customer and define problems from a human perspective. Scrum implemented properly looks a lot like the design thinking process. The LEAN Plan-Do-Check-Act (PDCA), especially its Toyota created implementation as an A3 Report, are strikingly similar to the design thinking process as a whole. Moreover, the Agile and DevOps philosophies at large seem to naturally resonate with the design thinking methodology.

Despite all the similarities, there are 3 things which we need to absorb from the Design Thinking community that we often neglect at our peril.

The first is that humans must always be at the center of creation. Systems, however complex they may be, ultimately serve one or more humans. When we create systems which are optimal for their own sake we create an environment which turns humans into machines. Humans should create machines, not serve them.

The second is that there is never only one solution, we must explore and try as many as possible. The LEAN Startup of Eric Ries (which is really from his mentor Steven Blank) introduced the concept of Minimal Viable Product (MVP). The intention of an MVP is to invest the absolute minimum required effort to produce something to sell a potential consumer. If the customer doesn’t want to buy what you’re selling them, you need to know as soon as possible and change your approach, or pivot, towards what they will buy. Today, however, companies invest months or year on a “beta” which they then call an “MVP”, when in fact they left the MVP stage after the first week of effort invested. Prototyping enables quick experimentation and evaluation to iterate closer and closer to the solution your customer (whoever the customer is) wants and that means simple, fast, and iterative.

Finally, and perhaps most importantly, in order to create new and innovative solutions we must, by definition, stop acting like integrators who assemble a variety of available piecemeal solutions together to simply arrive at a solution as quickly as possible. We must step back from the problem, allow ourselves to empathize with the stakeholders and realize that the existing situation is a result of its place within a system which supports it. We must understand the entire system, the problem in its full context, and then define the problem within that systems context. Only then can we ideate true “break out” solutions which change the game, which constitutes true innovation.

Design Thinking is a powerful focusing lens and set of methodologies which can help reinforce our existing practices and improve upon them. It is a trend that already holds a central place in the world around us and one that we can learn and embrace.

2015 marks an important evolution in the DevOps movement, the adoption of design thinking principles. Several of us in the community have independently come to an appreciation of it. Jeff Sussna gave what I believe to be the best talk of 2015: From Design Thinking to DevOps and Back Again: Unifying Design & Operations (https://vimeo.com/129939230) and, moreover, LEAN UX 2015 showed itself to be the most important conference of the year by embracing the design thinking approach into a wide variety of tech disciplines, beyond just UX. This is a trend I hope to see expand greatly within the coming year!