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

So what should an ‘agile architect’ be doing?

“So many architects walk around with the world on their shoulders. The responsibility of figuring out all this ‘stuff’ is supposedly taxing. Screw that… You are a creator… Go create…”

Agile Architect in his natural habitat.jpg

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

I recently wrote a blog on whether software architecture matters. It was a quick stream of consciousness hacked out in record time like most of my blog entries (probably riddled with grammatical errors and spelling mistakes). And like many of my blog entries it got a few muted grumbles from my extended professional network, especially from those that are ‘architects’ by trade.

The one thing that all of the grumbles had in common was the question of what I think a so called ‘agile architect’ should  be doing? This because I suggested that most of the design decisions should sit with the team. Not wanting to disappoint my somewhat less than usually chirpy ‘architect’ counterparts here is my list of things of things I believe we should be doing collectively:

1. Be part of the 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 devs is not good enough anymore.

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

3. Your job is to accelerate the project not to slow it down

Change priorities, trash requirements, architecture spike yourself to death. Whatever you do don’t stop the flow of value creation. There are many things that need to happen in projects. Many of those don’t need to stand still while perfect understanding (or consensus) is sought. Too many ‘architects’ plant their heels into the ground demanding big analysis when uncertainty is encountered. By nature they are top down thinkers that want to completely disseminate and understand a problem before making decisions. This however introduces a ton of friction into the development process. Defer as much decision making for as late as possible, outsource as much risk to others, focus on the really scary parts that can blow your design but don’t become another blocker.

4. Your job is preliminary about communication, do it often and early

It is really hard to create a shared understanding in the minds of everyone involved in a project (business, tech and design). Add different personalities, skills and backgrounds and it gets even harder. Heck even involving too many people or the wrong people too early is enough to explode the number of communication paths you have to contend with. So be transparent and open at all times. Trash complicated diagram standards and do everything in your power to drive context and understanding. Simplify and re-frame things over-and-over. Repeat this relentlessly until a semi coherent common understanding is reached and people start taking initiative on their own. Once that happens simply curate and make sure it is correct being careful not to trample and people’s attempt at contextualization.

5. Focus on the essence of the problem, the simpler the better

Stop creating artifacts, 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.

6. Test your architecture

POCs or Architecture spikes 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).

7. Question standards

Corporations are rife with cargo-cults that never question why they do the things that they do. “It is just the way it is done, or the standard”, is a common refrain. This is such a bullshit attitude that guarantees sub-optimal solutions. Be ruthless in questioning ordained “standards”. Especially if a “standard” is merely written down glorified opinion piece that has never been tested and validated.

8. Promote agile practices in other areas of the business

Unfortunately most organizations only embrace agility in their delivery teams. It is your job to promote lean and agile practices in the supporting functions that support the team.

9. The most important thing: Don’t take yourself so seriously

So many architects walk around with the world on their shoulders. The responsibility of figuring out all this “stuff” is supposedly taxing. Screw that… You are a creator… Go create great things with your teams, have fun with them and enjoy it. Stop taking yourself so seriously.

 

Agile Transformation: How to tell that you are failing…

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

Behold the agile transformation wizard, here to save the day!

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 gnawing urge to supplement the post with something a little more tangible and pragmatic.

So being a geek at heart I present to you my list of anti-patterns regarding agile transformation. For the less technically minded among us an anti-pattern is typically a documented recurring software problem that is usually ineffective and risks being highly counterproductive. They serve as a vocabulary to shape discussions about design based on past industry experience. Since Andrew Koenig coined the term in 1995 it has been adopted in fields other than software design, so I feel its a great succinct format to present my views with.

Anti Pattern: “Not my gig”

If your executive or management layer views “agile transformation” as something that is exclusively the domain of tech teams and if none of the other supporting functions are involved you might have a problem. Agile is a culture not a process or activity. If you only optimize the delivery function and not the supporting business functions all you are doing is over optimizing one aspect of your organization making it incompatible with the others. Agile transformation has to be an organization-wide activity including the executive layer or you are wasting your time.

Anti Pattern: “Don’t worry we’re experts”

If your army of agile experts and trainers only talk about methodologies and process then you have been duped and should strongly consider firing every single one of those expensive consultants on the spot. Agile coaching and scrum mastery are incredible difficult skill-sets to source for. The reason for this is because these roles are geared toward intangibles that are inherently hard to track and measure. Instead of parroting process or methodology the agile experts you are looking are individuals that continually cultivating the understanding that agility is a mindset and culture. The sad truth is that many agile experts are not experts at all. They are former project managers that need to stay relevant and subsequently went on scrum training (typically given by equally inexperienced agile experts). With the blind leading the blind all focus ends up on the tangible part of the role being process and methodology. Unless your agile expert has actually run a real agile project (at scale) and proven it to be a success in from the perspective of the (proper) agile community, you are missing the point.

Anti Pattern: “Madame Secretary”

Related to the “don’t worry we’re experts” anti pattern, the “madame secretary” can be spotted when a great majority of your scrum masters are merely acting as agile secretaries to their squads. Instead of doing any real coaching (or driving any changes) these individuals spend most of their time simply following the ordained agile events in a kind of weird check-boxing exercise. This happens a lot for scrum masters sourced from other roles or people that have been trained by one of these snake oil training merchants. Your agility team members should be students of the human psyche. They should be passionate about understanding human personality theory and should continually be coming up with experiments to improve the psychologically safe work environment of their teams. They should be obsessed by tracking every metric of team happiness. They should be an undeniable expert in their field. If a developer knows more about agile development than your scrum masters, you should be afraid, be very afraid.

Anti Pattern: “Waterscrumfalls hiding”

The waterscrumfall is already a known term but this anti-pattern takes the concept a bit further suggesting the intent behind it. Waterscrumfall refers to when your development teams are doing everything in their powers to run in an agile way, but all the other phases of the project don’t operate in the same way. This typically results in an over optimization of the development phase but unchanged slow moving cycles everywhere else resulting in sub optimal results. Now for the new bit. Agile is rough, it makes everything transparent for everyone to see. Developers embrace this since it beats having nobody else understanding what on earth they are up to. But this level of transparency might not sit well with some of the other more traditional functions in your organization. Waterfall was a great way to obfuscate many of the daily duties and tasks due to its inefficiencies. If you see signs of localized agile adoption it might be the unfortunate truth that there are some in your organization that prefer to hide from view.

Anti Pattern: “Functional Culture”

When cultural concepts get functionalized (and frequently centralized) you’re doing it wrong. Devops is a great example. Devops is a culture, it is a way to describe development and operations coming closer to one another. How do organizations respond? By hiring dedicated devops competencies and raving about them every opportunity. Operations personnel that fear for their future re-brand themselves and start singing from the devops hymn book. Team level devops activities get centralized to fancy new committees tasked with solving holistic problems establishing fancy new standards everywhere for everyone to use. If you are spinning up working groups, committees or new functions left, right and center around culture based concepts, you are doing it wrong.

Anti Pattern: “Just because”

Agile adoption should be tied to a tangible and inspirational goal. Unless there is a compelling ‘why’ as to why you are doing this transformation you will not succeed. Talking only about the ‘what’ benefits (like cost reductions or greater efficiency etc) is not going to get people to embrace a new culture shift. If you are getting a lackluster response from your people you should probably watch this excellent video by Simon Sinek, and reconsider your approach to leadership.

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.