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

Advertisements

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.

 

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