Thinking about design thinking

“Instead the British Design Council expressed it as an infamous double diamond diagram that happens to look fantastic on a slide.”

Designers

“Designers don’t search for a solution until they have determined the real problem.”

I recently wrote a piece on the differences between design thinking, lean and agile. Since then I have been wanting to explore each of the topics on their own. The reason for this is because each of the mindsets deserve their own unique place in the sun. They have their own origin story and shine in different ways and contexts. Of course they shine most when combined to complement one another.

So Design Thinking…

One of the biggest buzzwords around today. For many it brings up visions of creative types walking around with pretty presentations of honeycombs and Venn diagrams. Paired with elaborate flow charts describing how it all works lead many to believe that design thinking is about process.

“But like most well intended ideas in our industry it is not about process or procedure at all. Instead it is once again a mindset or culture.”

But like most well intended ideas in our industry it is not about process or procedure at all. Instead it is once again a mindset or culture. It just so happens that the mindset is paired with a set of techniques for applying a designer’s way of doing things.

But design techniques are just for design?

Not true! Design thinking can be applied to any context or domain with great effectiveness. It is a fantastic approach to explore and brainstorm new territories. As such it is less about the outcome and more about the approach and path to get there. Conventional thinking would have you think that this is not the case and that the “design” in “design thinking” implies outcome.

So if design is not about design what is it?

It is about lifting they way designers approach problems and using it elsewhere. As Donald Norman the father of UX said: “Designers don’t search for a solution until they have determined the real problem, and even then, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they converge upon their proposal. This process is called Design Thinking.”

I still don’t get it spell it out for me

Ok, so its not about stickies, sketches, honeycombs or process. It’s not even about actual UX design. Design thinking is a set of approaches where almost all flavors aim to:

  • Figure out what the real problem is instead of settling on the first solution
  • Search for solutions expansively frequently leveraging the intelligence of the group
  • Critically considering the options, narrowing it down to the best
  • Collectively converging on a proposal that should in theory be far superior

The idea is that the more avenues and directions you explore the deeper and more thoroughly you think about your problem.

So why the honeycombs and diamonds?

Let’s formalize the above paragraph. Design thinking is the repeated divergence, emergence and convergence of solutions to problems. As such, it is nothing but deliberate practice for continually solving things from a different starting point and in a far better way.

“But that is way to fluffy to try and explain to business folk conditioned to think in PowerPoint and email. So instead the British Design Council expressed it as an infamous double diamond diagram that happens to look fantastic on a slide.”

But that is way to fluffy to try and explain to business folk conditioned to think in PowerPoint and email. So instead the British Design Council expressed it as an infamous double diamond diagram that happens to look fantastic on a slide. That diagram has now become the ubiquitous way of simply visualizing the model. Honeycomb diagrams aim to do the same with a little more detail.

Double diamond.PNG

“Behold the famous double diamond, or at least one version of it!”

Remind we what this all about again

As I said in my original blog. Design thinking is all about exploring the problem. Lean is all about building the right thing. And agile is all about building the thing right. Design thinking allows us to explore using intuition and deductive reasoning just like a designer. Or at least in theory 😉

Advertisements

The difference between design thinking, lean and agile

“In a nutshell all three these concepts are mindsets (or principles that inspire culture) that when practiced correctly helps organizations develop new skills, abilities and competencies to respond to the modern world.”

Agile, Lean and Desing Thinking

“They are not the same thing but complement each other so well that they might as well be”

You would be hard pressed to go into a modern software development environment nowadays and not hear these three terms being used liberally by business and tech alike.

However like so many industry concepts you will find that people tend to have very different views on what these terms mean and how they should be applied. Some would see them as being the same thing (or at least virtually the same). Some may perceive them as processes and techniques to be followed by the book. Others will deny that they are things or processes and that they rather represent mindsets or cultures that should be embraced.

But it need not be confusing. In a nutshell all three these concepts are mindsets (or principles that inspire culture) that when practiced correctly help organizations develop new skills, abilities and competencies to respond to the modern world. All three attempt to make every organizational action a learning opportunity driving better decisions and new ways of working.

Each mindset brings its own value to a different part of the product life cycle. As such they are not the same thing but complement each other so well that they might as well be.

I can’t remember where I picked it up but my favorite way of summarizing the difference is with the following three sentences:

  • Design thinking is about exploring problems in a better way
  • Lean is about building the right thing
  • Agile is about building the thing right

If you take anything out of this article these three sentences would be it. But let’s scratch that surface just a little bit more.

Design thinking at a distance (Explore problems better)

Design thinking leverages techniques and practices that designers have used to overcome the weaknesses in traditional brainstorming to better explore complex problems that exists in uncertain environments. It draws heavily on empathetic thinking and the constant re-framing of problems (and potential solutions) from the perspective of the humans in the process. It is not limited to design and these techniques can be applied to almost any domain that would benefit from a less rigid approach or departure point.

Lean thinking at a distance (Build the right thing)

Famously tying its origins back to the revolutionary Toyota Production System and its father Taiichi Ohno, lean is the management philosophy that embraces scientific thinking when considering strategic decisions about how, when, where and how work gets done in an organizational value stream. It recognizes hard realities about constraints and uses it to focus improvement efforts where it matters most. It promotes the use of deliberate practice to create habits that result in a highly responsive and outcomes focused organization obsessed with value creation.

Agile thinking at a distance (Build the thing right)

Agile is not a noun, it is an adjective. And at the heart of having agility in your ways of working is adapting to changing needs and deferring decision making to the last responsible possible moment in time when you have the most possible information to make the right decision. It focuses on constant value creation typically through short iterative cycles of focused work that can easily adapt to almost any domain. Quality is not a goal but as a continuously integrated facet of your daily work.

So which one of the three is the most important?

Well this is awkward. The strengths of each of these concepts present themselves under different circumstances. As such, you cannot really compare and say one is more important than another. As such you should not be trying to figure out how to do one above another. Rather see them as a powerful trio that when done together can take your organization to new heights. In geek parlance it is ! an || but an &&.

Cultivating a cause worth believing in for software teams…

“By design they care gravely about where they plow their trade and by virtue of their idealistic natures they are looking for something that they can believe in.”

The lonely road of vision of leadership

“In order to land the best talent in industry, you need a purpose or an idea that people can rally behind. More importantly it has to be real and speak to the hearts and minds of people on whatever path they may be on.”

Anybody that has tried to build a software development competency will tell you that it is really hard to hire well. The reason for this is due to the fact that one is searching for a very unique type of individual. Individuals that are extremely idealistic in nature,  can think critically and are pragmatic when needed. Yet the same individuals have to have a healthy dose of creativity and artistry allowing for abstract thought and non linear thinking.

Of course there are certain organizations, individuals and teams that don’t care about culture. For them its easy to hire since it essentially just becomes a numbers game. A rough checkbox marking exercise where you just find people that kinda look right and throw money at them. But I am not referring to these toxic cultures.

I am rather talking about those organizations that don’t view delivery as mere ‘resources’. Those organization that realize that the culture one builds is the thing that actually creates whatever outcome you are looking for.

“If they wanted just another ‘job’ they could have it a few days of interviewing.”

In healthy organization such as this, to find the aforementioned individuals can be excruciatingly hard and time consuming. They regularly get approached by recruiters with offers and they have a veritable pick of a wide range of opportunities. If they wanted just another ‘job’ they could have it a few days of interviewing. But for these individuals it not just about another ‘job’. By design they care gravely about where they plow their trade and by virtue of their idealistic natures they are looking for something that they can believe in.

The right individuals don’t see their careers as just a ‘job’, but rather a calling. They are passionate about the craft that they have spent years honing and want to use it to build great things. They want to be trusted and empowered to use their craft and certainly don’t want others to dictate to them how they should be using their craft.

Understand that these people are not stupid. They are hyper intelligent, well educated and ruthlessly clinical in their thinking. This means that they can smell bulls@#$ a mile away.

“Lots of corporations think that they can attract a lure talent by talking a big game, manufacturing unauthentic ideals/values/visions and engaging in imitation innovation to show ‘coolness’.”

Lots of corporations think that they can attract a lure talent by talking a big game, manufacturing unauthentic ideals/values/visions and engaging in imitation innovation to show ‘coolness’. This type of behavior will only fool people for so long if it is not truly part of the organization’s DNA.

In order to really land the best talent in the industry, you need a purpose or an idea that people can rally behind. And more importantly it has to be real and speak to the hearts and minds of people. This vision that you share with people has to have integrity or it will simply fail.

Secondly, behind this vision should sit a leader that is not just a salesman but who cares (and regularly shows) a responsibility for the careers (and by extension the lives) of the people that choose to follow the vision.

Now the natural reaction for people outside of technology is to view such views with a healthy dose of resistance. Statements around technology not being unique or that everyone should be treated the same way would be common. And they are right, everyone should be treated the same. But that treatment should be more in-line with the way technology wants to be treated.

The corporate cargo cultures frequently miss this point. What technologists are after is an environment that has moved on from the traditional command-and-dictate structures of the industrial era. A flat networked styled organization in-line with the modern knowledge economy. And since most white collar workers are also participants in the knowledge economy, they likely seek the same goals of autonomy, mastery and purpose that the geeks wane about all the time.

Whether we want to admit it or not, software has and continues to drive the modern industrial revolution. It is therefore at the forefront of shaping what modern organizations culture should and could be. So instead of taking a defensive position and mounting the delicate snowflake attack, realize that your delivery team culture is a testing ground for your organization’s future culture. The really interesting thing is that if you pass the test with hyper-critical geeks, it means that your cultural values will undoubtedly work well in all areas of your organization.

“Having a cause that you believe in as a leader is not enough. In order to galvanize and motivate others you have to translate that belief into something tangible and meaningful to them.”

But how to make it real? Having a cause that you believe in as a leader is not enough. In order to galvanize and motivate others you have to translate that belief into something tangible and meaningful to them. Everybody works for their own selfish reasons and unless people can clearly see what it is that is in it for them, they will not care. If you are honest and sincere, and can successfully translate your vision in a tangible way to others then you have the makings of a movement.

And there are warning signs. For example if your top technologists and leaders are continually in debates about how to achieve something instead of focusing on what. This is a tell tale sign that the cultural foundations are weak and are at risk of failure.

Daniel H. Pink is a renowned author on this subject matter and certainly his book Drive should be read by every ‘leader’ in business. But to end this somewhat long article I think it is appropriate to borrow some of his swag with a quote.

“While complying can be an effective strategy for physical survival, it’s a lousy one for personal fulfillment. Living a satisfying life requires more than simply meeting the demands of those in control. Yet in our offices and our classrooms we have way too much compliance and way too little engagement. The former might get you through the day, but only the latter will get you through the night.”

The learned helplessness of corporate companies

“I don’t necessarily want to elaborate on all the details of the experiment but in a nutshell it pretty much involved electrocuting dogs in controlled experimental chambers where their only option was to take the shock.”

Learned helplessness in corporate companies

It is really hard not to become despondent in bureaucratic organizations

One of the strangest things that I have witnessed in many bureaucratic organizations is the phenomenon of learned helplessness.

In 1965 Martin Seligman and his colleagues were doing research on classic conditioning. I don’t necessarily want to elaborate on all the details of the experiment but in a nutshell it pretty much involved electrocuting dogs in controlled experimental chambers where their only option was to take the shock. The negative conditioning (zapping fluffy) when done enough induced a sort of learned helplessness in the dogs leading them to avoid seeking potential escape. Even when the configuration of the chamber was changed with an obvious exit in plain sight, the poor creatures still settled for the familiar negative reality of being shocked.

I believe that most corporate environments are like these chambers. There are simply too many people in what is more than likely a heavily regulated industry working in archaic ineffective ways with teams structured in Orwellian like configurations. In such a space if you put one foot wrong or deviate one iota from the ordained norm there is a generous amount of individuals that will stand in line to tell you how what you are trying to achieve is simply not possible and contrary to what is expected. These self-anointed guardians of all things process will then place as many obstacles in your way to prevent you from deviating from the learned norm.

The go-to argument most of the time is governance. The sad truth is that in these toxic environments the norm has become for people to use governance and regulation to build intricate systems of excuses whereby they can absolve themselves from ever having to take any accountability for real change or progress. This self-induced learned helplessness gets passed on from culture to culture, team to team until the vast majority of organization live in an eternal state of feeling hamstrung and dis-empowered, never venturing beyond the safety of their constant suffering.

To be fair most of these individuals have been smacked so many times by the same forces of self-induced learned helplessness in others that you can’t blame them for losing hope. It is really hard not to become despondent when facing the illogical reasoning of some of the hurdles that get placed in front of change agents.

There is however one even bigger evil that lurks in the shadows of learned helplessness. It comes in the form of the few that have learned how to exploit the learned helplessness for their own political benefit. The ones that dramatize and use the hyped up implications of these self-imposed governance policies to manufacture artificial urgency in teams and people. This fear based approach forces people to continually go above and beyond to get things done frequently for their own narrow need. In the process employee well-being frequently gets destroyed. This type of behavior almost always obliterates any hope of having a caring psychologically safe environment and can so easily become the norm for a learned helplessness infused environment.

So in closing, all leaders face constraints. I don’t for one second suggest that there is not real constraints placed on many industries. But true leaders differentiate between constraints that must be accepted and those that can be challenged. True leaders show their people that it is not only okay to go against the grain, but that they will be supported by the leader in that moment when they want to make a stand against the machine.

Why corporate companies suck at agile

“Sticking feathers up your butt does not make you a chicken.” – Tyler Durden

Why corporate companies suck at agile

Agile has become like a religion where everyone in corporations feverishly beat their breasts and shout at the top of the voices for all to hear how great it is.

It is amazing that 16 years after the agile manifesto came to life that many corporate software environments still talk about ‘Agile Transformation’. Agile has become like a religion where everyone in corporations feverishly beat their breasts and shout at the top of the voices for all to hear about how great Agile is and how totally on board they are with it. For many business professionals it has even become a career risk not to buy into the virtues of Agile.

For those paying close attention you will notice that when corporate environments talk about agile development, (like the paragraph above) they tend to talk about it in capitalized noun form. Agile development has been reduced in substance and is simply seen as a process or framework that needs to be adopted. It is seen as a magic bullet that is finally going to solve the inefficiencies in those pesky technology departments that just don’t get the subtleties of high brow business folk’s needs.

The problem is that this capitalized noun Agile mindsets miss the point completely. In the immortal words of Tyler Durden, ‘sticking feathers up your butt does not make you a chicken’. Similarly taking an agile (read nimble) process/methodology and following its steps to the tee without really understanding its purpose does not make you an agile organization. It was never about process or framework.

Agile is an adjective, it describes a culture and mindset. A desire to be adaptable, collaborative, lean and evolutionary. Agile is about early feedback loops, about failing early and fast. It is about constantly reflecting on yourself and coming up with experiments to improve things. It is about partnering with your client and involving them in the development process.

It is about transparency and externalizing risk at all times. Its about building products lean and incrementally. It is about accepting that you don’t have all the answers up front and using natural ways of working to figure them out just in time when they are needed.

If these words resonate with you I implore you to go read the agile manifesto again and to start focusing on the values and principles behind agile development instead of fixating on process. Be mindful of how people become fundamentalists about something they do not even truly understand in the first place.

We need to stop the army of Scrum Alliance trained ‘Agilists’ that parrot fashion recite SCRUM methodology to you claiming to be the answer to your waterfall world.