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.

Agile Transformation: The Warning Signs of Failure…

“As a geek at heart, I present to you my list of anti-patterns regarding agile transformation.”

I present to you my list of wizardly anti-patterns regarding agile transformation…

I recently did an article about ‘why corporate companies suck at agile‘. Since writing that post, I have had a nagging urge to supplement the post with something more tangible and pragmatic.

As a geek at heart, I present to you my list of anti-patterns regarding agile transformation:

Not my gig – If only your tech teams are involved in the agile transformation, without the support of other functions, you may be setting yourself up for failure. Agile is a culture, not just a process or activity, and it needs to be embraced by the whole organization, including executives, to be effective.

Don’t worry, we’re experts – If your agile experts and trainers only focus on methodologies and processes, they’re not doing their job. Agile coaches and scrum masters should be experts in the intangible aspects of the role, such as cultivating a mindset and culture of agility. If they’re only parroting process and methodology, they’re not true experts.

Madame Secretary – If your scrum masters are acting as secretaries to their teams, rather than coaching and driving change, they’re not fulfilling their role. Scrum masters should be students of the human psyche, constantly experimenting to improve the psychological safety of their teams and tracking metrics of team happiness. If a developer knows more about agile development than your scrum masters, it’s a red flag.

Waterscrumfall – If your development teams are running agile, but other phases of the project are not, it’s a sure sign that your agile transformation is not being implemented consistently. This can lead to over-optimization of the development phase and incompatibility with other parts of the organization.

Agile theatre – If your organization is going through the motions of agile, but not actually embracing the culture and mindset, it’s a clear sign of failure. Agile transformation requires a real commitment to change, and if it’s not happening, it’s time to reassess your approach.

Unrealistic expectations – If you set unrealistic expectations for what your agile teams can accomplish, you’re setting them up for failure. Agile is about making small, incremental improvements, not achieving overnight success. Make sure your goals are realistic and achievable.

Lack of commitment – Agile transformation requires a genuine commitment from everyone involved. If some members of your organization are not fully on board, it will be difficult to achieve success. Make sure everyone is committed to the process and willing to work together.

Micromanagement – Agile teams need space to operate and experiment, but if they are being micromanaged, they will be unable to do their best work. Allow your teams the freedom to manage their own processes and make their own decisions.

Lack of transparency – Agile teams thrive on transparency and open communication, but if these values are not present in your organization, it will be difficult to achieve success. Make sure everyone is aware of what’s happening, and encourage open and honest communication.

Ignoring feedback – Agile is all about continuous improvement, and that requires listening to feedback from team members and stakeholders. If you’re not paying attention to feedback and using it to make changes, your agile transformation will not be effective.

Functional Culture – If you’re turning cultural concepts into functional roles or committees, you’re not embracing the true spirit of agile. DevOps is a great example of this. Rather than hiring dedicated DevOps personnel or creating committees, true agility comes from fostering a culture of collaboration and communication between development and operations.

Just because – Agile transformation should be driven by a clear and inspiring goal, not just because it’s the latest buzzword. If you’re not getting buy-in from your team, it may be because you haven’t communicated why the transformation is important and how it will benefit everyone involved. Make sure you have a compelling “why” to inspire your team and drive change.

Why corporate companies suck at agile

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

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 beats their breasts and shouts at the top of their 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. It’s 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 the 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 recites SCRUM methodology to you claiming to be the answer to your waterfall world.

But the real issue is that corporations are not set up to be agile. Corporations are built to optimize control and stability. They are built to make money by minimizing risks and maximizing profits. They are built to have long-term plans and to execute them. They are built to have policies and procedures in place to ensure consistency.

All of these things are anti-agile. Agile is about embracing change and uncertainty. It is about experimentation and learning. It is about short-term goals and flexibility. It is about trust and collaboration.

In order for corporations to truly embrace agile, they need to fundamentally change the way they operate. They need to start valuing adaptability and learning over control and stability. They need to start prioritizing experimentation and innovation over minimizing risks and maximizing profits. They need to start focusing on adaptable goals and flexibility over long-term plans and control. They need to start building trust and collaboration over policies and procedures.

This is no small task. It requires a complete shift in mindset and culture. It requires senior leaders to lead by example and to truly understand the nature of the beast.