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 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.

“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 😉

Advertisement

The difference between design thinking, lean and agile

“Each mindset brings value to a different stage of the product life cycle and, when used together, can drive better decision-making and improved ways of working.”

“Instead of trying to prioritize one over the others, it is better to view them as a powerful trio”

In modern software development, you’ll often hear the terms design thinking, lean, and agile. While people may have different interpretations of what these concepts mean and how to apply them, they all share the common goal of helping organizations develop new skills and abilities to adapt to the modern world. Each mindset brings value to a different stage of the product life cycle and, when used together, can drive better decision-making and improved ways of working.

I can’t remember where I picked it up but my favourite 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 is a problem-solving approach that utilizes techniques and practices from the design field to overcome the limitations of traditional brainstorming. It focuses on empathy and the continual reframing of problems and potential solutions from the perspective of the people involved. Design thinking is not limited to design and can be applied to any domain that would benefit from a flexible and human-centred approach.

Lean thinking at a distance (Build the right thing)

Lean thinking is a management philosophy that originated with the Toyota Production System and its creator Taiichi Ohno. It involves applying scientific thinking to strategic decisions related to the execution of work in an organizational value stream. Lean recognizes the importance of addressing constraints and focuses improvement efforts on creating value. It also emphasizes the use of deliberate practice to develop habits that enable a highly responsive and outcomes-focused organization.

Agile thinking at a distance (Build the thing right)

Agile is an adjective that describes a way of working that is adaptable to changing needs. It involves deferring decision-making until the last responsible moment when you have the most information to make the right decision. Agile thinking focuses on constantly creating value through short, iterative cycles of focused work that can be applied to almost any domain. Quality is not a goal, but an integrated part of daily work.

So which one of the three is the most important?

It is difficult to compare the importance of the three concepts discussed in the previous paragraphs because their strengths are applicable in different situations. Instead of trying to prioritize one over the others, it is better to view them as a powerful trio that can achieve great things when used together. In programming terms, this is not a logical “or” (||) but a logical “and” (&&).

So what should an “agile” software architect be doing?

“As architects, you have the opportunity to create spaces that inspire, uplift, and bring people together.”

“An agile architect in his natural habitat dancing in a field of complexity…”

I recently wrote a blog on whether software architects matter. The blog was written quickly and without much consideration, which sparked discussions among my professional network, particularly among architects. Many of these discussions focused on the role of an “agile” software architect. My suggestion that most design decisions be made by the team appeared to be the trigger point for these discussions. In light of this, I have compiled a list of things that I believe “agile” software architects should be doing:

Be part of the development team – You are there to inform, motivate, and influence the team without expending social capital by forcing your decisions. Being removed from the actual development effort and simply flinging architectural documents (that probably don’t reflect actual system code) at developers is not good enough anymore.

Adapt to the team’s way of working – Not the other way around. In order to build high-performance teams, you need to create space for autonomy, mastery, and purpose. The autonomy boundary can be constrained, but each team’s sweet spot in terms of their way of working will differ slightly. Standardizing your approach will simply lack the flexibility and variability that modern teams need and require.

Your job is to accelerate the project, not to slow it down – Your goal is to keep the project moving forward and avoid slowing it down. Be flexible and willing to change priorities, discard unnecessary requirements, and experiment with new ideas. Above all, keep the flow of value creation going. Don’t get stuck trying to understand or gain consensus on every detail. Instead, defer decision-making as long as possible and focus on the high-risk areas that could derail your design. This will help you avoid becoming a bottleneck in the development process

Your job is primarily about communication; do it often and early – Keep the lines of communication open and start early. It can be difficult to achieve a shared understanding among all project stakeholders, but transparency and simplicity can help. Avoid complicated diagrams and strive to provide context and understanding. Repeat key points until a common understanding is reached and people start taking initiative. Then, simply curate and ensure accuracy without stifling people’s attempts to contextualize the information.

Focus on the essence of the problem, the simpler the better – Stop creating artefacts, documents, and stuff that nobody can contextualize. Even if you have to explain things over and over again, this will refine the concept in your head and provide extra insights. Look at initiatives like C4 diagrams to get your drawings more in line with the actual thing being built.

Test your architecture – Prototypes and POCs are single-handedly the best way to validate parts of your architecture. But in too many organizations, this is seen as a waste of time and money. Change the way you fund projects and cater for this activity. While you are at it, always add slack for testing the non-functionals of your architecture (scalability, performance, and robustness).

Question standard practices and seek out new ideas – Don’t be afraid to challenge the status quo and seek out new ideas and approaches. The world of software development is constantly evolving, and it is important for architects to stay current and adapt to new methodologies and technologies. This will help you to stay relevant and effective in your role.

In conclusion, the role of the agile architect is to be an active and influential member of the development team, adapt to the team’s way of working, accelerate the project, communicate effectively, focus on the essence of the problem, test the architecture, and seek out new ideas. By following these principles, you can help your team to build better software and achieve greater success.

Lessons I Wish I Had Learned in My Twenties

“Just because we may lack the vocabulary to adequately express our emotions, it does not mean that we do not feel. Emotions are what make us human, and they are where all the magic lies.”

“The world is transitory, and nothing lasts. Change is inevitable, but growth is optional..”

This post is primarily for me, but I wanted to share my thoughts with anyone who may be listening. Self-knowledge is the only way to undo the harm caused by years of self-indoctrination at the hands of our superegos. Acting from a place of authenticity and true self-knowledge is the key to contentment. Contentment is the goal, because it is a steady state, unlike happiness which is fleeting by definition. Chasing and trying to extend happiness will only dilute moments of true happiness and leave us wanting more, making us slaves to it. Be compassionate to those who are still enslaved by the tormentors of their superegos, as we have all been there at some point.

It is important to remember that we are human beings and being human means having emotions. Just because we may lack the vocabulary to adequately express our emotions, it does not mean that we do not feel. Emotions are what make us human, and they are where all the magic lies. Intellect may be useful, but it is not the key to happiness. We have the right to feel, regardless of how “big” or “small” our emotions may seem to us. Our feelings are not comparable and have no “size”. We also have the right to express our feelings, as long as we do so in a responsible and respectful way. We should never feel compelled to suppress what we believe and feel at our core.

It is important to be kind to ourselves and to others. We should be mindful of our thoughts and ideas at all times, and be aware of how anger, greed, and disillusionment can create images and situations that prevent us from gaining true self-knowledge. We should never try to force others to be what we want them to be. Doing so will only damage the core of that person, and will spread seeds of discontent. This is especially true in relationships, where it is easy to want to create the perfect image of what a “relationship” should be.

The world is transitory, and nothing lasts. Change is inevitable, but growth is optional. We should embrace change as a tool to foster constant growth. Avoiding change means reliving the same predictable experience over and over until we die, which is a waste of our time. Instead, we should explore what is holding us back from leaving our comfort zones and embrace change from a place of true self-knowledge. Otherwise, our desire for change may be driven by a narrative playing in our heads that is based on a lie.

Ultimately, nothing matters. We can either become bitter about this, or we can use this knowledge to make the most meaning out of the time we have in this fleeting experience. Discovering meaning in life is enjoyable, and it also helps us realize how little everything else actually matters in the grand scheme of things. A healthy body and mindset are prerequisites for a content soul. Contentment cannot exist in a toxic body and mind. We should never live with the dogma and thoughts of others, and we should not attack the dogma of others unless they try to force it on us or if it is clearly harming others. If someone derives happiness from their beliefs, it is not our place to try and destroy the foundations of what makes them happy. We should not be arrogant and assume that we know better, as our own “enlightenment” may be just as silly to someone else who is even more “enlightened”. In the end, it is all bull…

Developing a Culture of Meaning for Software Teams

“This means having a clear and compelling vision that speaks to the hearts and minds of potential team members. This vision needs to be real and have integrity.”

“To truly land the best talent in the industry, you need to have a cause or idea that people can rally behind.”

Building a successful software development team is a challenging task. Not only do you need to find individuals who are skilled in their craft, but they also need to have a certain mindset and approach to their work. They need to be idealistic and creative, but also able to think critically and pragmatically. They need to see their careers as a calling, not just a job.

Finding these kinds of people is difficult, and they are often in high demand. They regularly receive offers from recruiters and have a wide range of opportunities to choose from. As a result, to attract the best talent, you need to offer something that they can truly believe in.

This means having a clear and compelling vision that speaks to the hearts and minds of potential team members. This vision needs to be real and have integrity, and should be backed by a leader who is not just a salesperson, but someone who genuinely cares about the people who choose to follow that vision.

Many organizations try to attract talent by talking a big game and manufacturing unauthentic ideals, values, and visions. They try to show how “cool” they are by engaging in imitation innovation. But this kind of behavior can only fool people for so long if it is not truly part of the organization’s DNA.

To truly land the best talent in the industry, you need to have a cause or idea that people can rally behind. And you need to create a culture that aligns with the way that technology professionals want to be treated. This means moving away from traditional command-and-control structures and towards a flatter, networked organization that is in line with the modern knowledge economy.

Software has and continues to drive the modern industrial revolution, and as a result, it is at the forefront of shaping modern organizational culture. Instead of trying to fit technology professionals into existing corporate structures, organizations should strive to create cultures that align with the values and goals of the people who work in technology.

To do this, organizations need to prioritize autonomy, mastery, and purpose in their culture. They need to trust and empower their team members to use their skills and experience to build great things. They need to provide opportunities for growth and development, and create an environment where people can learn from each other and push the boundaries of what is possible.

Of course, creating this kind of culture is not easy. It requires a commitment to change and a willingness to challenge the status quo. It requires leaders who are willing to listen and learn from their team members, and who are willing to adapt and evolve in response to feedback.

But the payoff is worth it. A culture that aligns with the values and goals of technology professionals will attract the best talent in the industry. It will foster innovation and collaboration, and it will enable your team to build great things together. And in the end, that is what truly makes a software development team successful.

Do software architects matter?

“In order to be effective, the role of the software architect should be closely tied to the act of coding.”

One of the most problematic versions of this role is when someone without a technical background starts making pronouncements about architecture and is labelled as an architect…

The role of the software architect in software development is an important one, but it is often misunderstood and can be problematic if not approached correctly. The term “software architect” often conjures up images of a senior engineer who has mastered their craft and no longer needs to engage in the mundane task of coding. They sit in their ivory tower, making grand pronouncements about how software should be built and then bemoaning the inability of others to execute their vision.

However, this approach is misguided and can lead to a number of problems. For one, it creates a disconnect between the design and the implementation, which can result in unrealistic expectations and poor decision-making. Additionally, it can foster a lack of ownership and responsibility among the development team, leading to subpar results.

In order to be effective, the role of the software architect should be closely tied to the act of coding. This means that there should be no distinction between architecture and coding – it should be a shared concern of the autonomous team building a system collaboratively. This approach allows for a more well-rounded understanding of the design, as well as fostering a sense of ownership and responsibility among the entire team.

Of course, it’s helpful to be able to articulate architecture and the impacts of technical decisions in a way that non-technical people can understand. But this is a skill that every technologist should strive to perfect, not just those who carry the title of “architect.” Clear communication is essential for ensuring that all stakeholders have a shared understanding of the design and its implications.

One of the most problematic versions of this role is when someone without a technical background starts making pronouncements about architecture and is labelled as an architect. They are likely to be completely unaware of the subtleties of technology frameworks and the practicalities of building coherent software systems. This can lead to unrealistic expectations and poor decision-making. Yet, these individuals are common in corporate environments.

So, what is architecture, if anything at all? Martin Fowler’s view is that if there is such a thing as architecture, it is about creating a shared understanding within your team and investigating and answering the things in your project that will be hard to change in the future. The rest can be left to your capable and trusted development team. By focusing on collaboration and clear communication, the role of the software architect can be valuable in ensuring the success of a software project, provided is rooted in authentic knowledge.

Estimates, commitments, and targets in software projects

“Many people don’t even know that there is a difference that has led to countless project failures.”

Most people have never learned what good software estimation looks like or how to communicate it effectively.

The importance of understanding the difference between estimates, commitments, and targets in software projects

In my previous article, I discussed the inherent complexity of doing software estimation and the phenomenon of discovered complexity. Beyond this complexity lies another problem: poor communication. Most people have never learned what good software estimation looks like or how to communicate it effectively. Business people involved in software projects often view estimation as the domain of the technical team and make no effort to understand its nuances. Technical team members, on the other hand, often rely on gut-feel estimates without understanding the importance of clear communication.

As a result, estimates are often treated as commitments, and commitments are communicated as targets. Many people don’t even know that there is a difference between these concepts. This lack of understanding has led to countless project failures and eroded trust in the software development process.

To clarify the differences between these concepts:

• An estimate is a best guess at how long something will take, based on the information available at the time. As I explained in my previous article, estimates are inherently flawed and will change as more information becomes available and problems are solved. A good estimate should be plotted against a probability curve to quantify the uncertainty and risk surrounding it. Rather than communicating a single point estimate (e.g. “I think this will take 6 months”), it’s better to communicate a range (e.g. “given what we know, this could take anywhere from 6-9 months”). Thinking of estimates as a range of possibilities reduces the stress of having to be perfectly right and accommodates the inherent ambiguity and uncertainty of the software development process.
• A commitment is a promise to deliver functionality at a certain level of quality by a certain date. It’s critical to realize that estimates inform commitments, but commitments should never drive estimates. The working position should be that the estimate is flawed and commitments should be based on the most pessimistic estimate, allowing for additional buffer time. If the estimate is not acceptable, business stakeholders should prioritize the project and make the hard choices necessary to give it a quantified chance of success.
• A target is a single-point hard deadline, usually driven by external factors such as a product launch or a regulatory requirement. Targets are not based on estimates or commitments and are often imposed on a project team without their input. Meeting a target can require significant compromise on scope, quality, and/or timeline.

In summary, it’s essential to understand the purpose and value of software estimation and to communicate estimates, commitments, and targets clearly and accurately. By doing so, we can avoid the frustration and trust erosion that often results from project failures.

The Silent Devastation Caused by “Ideas People”

“Generating ideas is not a special talent reserved for a select few people who have been blessed with some kind of mystical ability to predict the future.”

Behold the unicorn ideas person. Full of ideas and low on execution.

In the software industry, you often come across individuals who are referred to as “ideas people.” These are people who are always talking about the big ideas they are “working” on. They might even insinuate how groundbreaking their idea is and how it’s going to change the world. These individuals often have a seemingly endless supply of ideas and can quickly switch between them, talking about each one with equal enthusiasm. If someone else in the industry has had success with an idea that resembles one of theirs, they may lament the fact that they didn’t pursue it and blame external circumstances for their failure. They may hold onto these ideas for years, waiting for the perfect moment to put them into action.

The worst part is that their passion for their ideas is often mistaken for genuine vision. Some people may be fooled into thinking that these individuals are true visionaries, and they may even receive funding from investors who are taken in by their rhetoric. When these ideas fail (which is most of the time), the ideas people typically blame external factors for the failure. They may say that the market wasn’t ready for their product or that the investor funds ran out just before they were about to make a breakthrough. If they are not technically inclined, they may blame the developers for being too slow, too expensive, or too inexperienced. It’s rare for them to take responsibility for the failure of their ideas or to admit that their ideas were flawed. To do so would damage their egos, which are often the only things they hold dear.

In reality, there is nothing more useless in this world than an “ideas person.” Not only is it frustrating to deal with their egos and their misplaced protection of their ideas, but anyone can come up with ideas. Generating ideas is not a special talent reserved for a select few people who have been blessed with some kind of mystical ability to predict the future. In fact, if you look closely at the ideas that ideas people come up with, you will realize that they are often nothing more than imitations of innovation, with concepts copied from the successes of others.

True visionaries are not just dreamers, they are also doers. Dreaming is an important part of being a visionary, but you also need to be able to follow through and make things happen. Ideas without execution are meaningless and a waste of everyone’s time. Execution is king.

The devastation caused by ideas people is particularly pronounced in the corporate world, where these individuals can operate with minimal risk to their livelihoods or reputations. If their half-baked ideas fail in a corporate environment, it’s virtually impossible to determine the cause of the failure because there are so many factors that could have contributed to it. As a result, ideas people can often escape blame for the failure of their ideas.

In contrast, the startup world does a better job of separating the doers from the ideas people. In startups, execution is everything. There is no room for ideas without action. If you can’t build something that is useful to humanity and that people want to use, you’re done. It’s a brutal environment that rewards true visionaries who can execute their ideas and destroys those who are just in it for the sound of their own voices.

The difficult part is that you want to encourage innovation and experimentation in corporate environments to help the company evolve and grow. However, the people who are typically tasked with coming up with these strategies and product ideas are often not well-suited to executing them.

Project Delays: Why Corporate Companies Struggle with Accurate Estimation

“‘The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” – Bollinger, T

At the heart of this problem lies the phenomenon of discovered complexity.

Accurate estimation is one of the biggest challenges in software development. It’s a problem that has plagued the industry since its inception, and it’s one that elicits strong opinions from everyone involved in a project.

Every company has its own collection of horror stories about projects that have slipped catastrophically or seem to perpetually overrun their budgets and timelines. These delays can result in lost jobs, damaged careers, and, most importantly, destroyed relationships.

For some companies, this is such a common occurrence that the destruction caused by poor estimation has become the norm rather than the exception. In these environments, the trust between business and technology may be so eroded that any attempt at coming up with reasonable project estimates is regularly abandoned.

Instead, these companies are bombarded with unrealistic business demands that are labelled as “critical deliverables,” even though they are based on no quantifiable reality of effort. These “immovable” business targets are often arbitrarily tied to people’s KPIs, even before the feasibility of the work is explored. The recipients of these KPIs are typically people with no experience in software estimation and no understanding of the differences between an estimate, a target, and a goal.

At the heart of this problem lies the phenomenon of “discovered complexity.” For some reason, people view software development as a mechanical task similar to an assembly line in a factory. However, as research has shown (even mathematically), “the creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” In other words, software development is a creative process that requires a lot of thinking about unknown problems that constantly arise. These “accidentally discovered” problems can lead to more subtle and indirect problems that also need to be solved. This is called “accidentally discovered complexity.”

In simpler terms, at any given point in time, you don’t know what you don’t know yet, and there’s no way to predict how long it will take to figure it out when you do discover it. In this world, how can you accurately estimate how long something will take? At best, you can make a reasonable guess based on the information you have at that moment. But even this is problematic because the information you have about the problem domain changes and develops as the project progresses.

Given this, it seems virtually impossible to accurately estimate these creative tasks. Therefore, it’s essential to follow an iterative development methodology that includes a constant feedback loop for estimates. If you’re not continually re-estimating how long a piece of work will take based on all the new information you learn, you’re putting your project, and more importantly, your organizational goals and commitments, at risk. Do that often enough, and you’ll see the consequences unfold.

The learned helplessness of corporate companies

“In a nutshell, the experiment involved exposing dogs to controlled electric shocks in a confined space.”

It is really hard not to become despondent in bureaucratic organizations

One of the most common and destructive phenomena in bureaucratic organizations is the concept of learned helplessness. This term was first coined by Martin Seligman and his colleagues in their research on classical conditioning in the 1960s. In a nutshell, the experiment involved exposing dogs to controlled electric shocks in a confined space. The negative conditioning of the shocks eventually led the dogs to avoid seeking potential escape, even when the chamber was altered and an obvious exit was presented. This phenomenon is known as learned helplessness, and it can have devastating effects on individuals and organizations.

In many corporate environments, the negative effects of learned helplessness can be seen all too clearly. There are often too many people working in heavily regulated industries, using outdated and ineffective methods, and organized into hierarchical teams that stifle creativity and innovation. In such environments, even small attempts to deviate from the norm can be met with resistance and obstacles from self-proclaimed guardians of the status quo. The go-to argument in these cases is often governance and regulation, which are used as excuses for inaction and a lack of accountability for real change.

This self-imposed learned helplessness is often passed on from one team to another, and from one culture to another, until the majority of the organization becomes trapped in a cycle of feeling powerless and unable to break free from the safety of their constant suffering. It is no wonder that many individuals in these environments lose hope and become despondent.

One of the biggest dangers of learned helplessness is the way it can be exploited by those who seek to gain political advantage. These individuals often exaggerate the implications of self-imposed governance policies, creating artificial urgency and forcing people to work beyond their limits for the benefit of a few. In the process, employee well-being is frequently sacrificed, and any hope of creating a psychologically safe and caring environment is destroyed.

In conclusion, all leaders face constraints, and it is not always possible to challenge them. However, true leaders are able to differentiate between the constraints that must be accepted and those that can be challenged. They also show their employees that it is okay to go against the grain and that they will be supported in doing so. By encouraging creativity and innovation, and by fostering a culture of accountability and empowerment, leaders can help their employees break free from the cycle of learned helplessness and create a more positive and productive environment.