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

Cultivating a cause worth believing in for software teams…

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

The lonely road of vision of leadership

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The delicate balancing act of estimates, commitments and targets

“The act of not basing commitments on tangible estimates might make stakeholders feel warm and fuzzy, but they are living a lie that will eventually catch up with them.”

Software Estimation balancing act

Most people have never learnt the balancing act of good software estimation and are pretty terrible at communicating it.

I recently did an article talking about the inherent complexity of doing software estimation. I delved into the phenomenon of discovered complexity and how it is at the heart of why it is so hard to do reliable estimation in software projects.

Beyond the inherent complexity of doing estimation lies another problem. One of bad communication. Most people have never learnt what good software estimation looks like or what the right way of communicating it is. Business people involved in software projects typically view estimation as the domain of the geeks and as such make no attempt at understanding the nuances. Geeks themselves have spent most of their lives giving gut-feel estimates never learning the importance of communicating estimates in the right way.

Universally estimates get treated as commitments and commitments get communicated as targets. Most don’t even know that there is a difference between these concepts.

The general disregard for the purpose and value of software estimation has led to untold amounts of project failures that in turn has caused unprecedented amounts of frustration and trust erosion in many business domains. And as already alluded to it all boils down to the fact that people simply don’t understand the difference between estimates, commitments and targets.

Each of these concepts have their own unique purpose, so allow me to disseminate it for you:

Estimate

An estimate is just that, it is best guess at how long something will take given the information that is known at this point. As I explained in my previous article, it is inherently flawed and will change over time as unknowns become known and problems find solutions that can be estimated on more reliably.

As such a good estimate should be plotted against a probability curve that tries to quantify the uncertainty and risk that surrounds the estimate. Put in simpler terms you should never communicate a single point estimate (‘I think this will take 6 months’) but rather a range (‘given what we know this could take anything from 6-9 months’).

“Thinking of estimates as a range of possibilities (between the best and worst case) reduces the stress of having to be perfectly right.”

Thinking of estimates as a range of possibilities (between the best and worst case) reduces the stress of having to be perfectly right and caters for the inherent ambiguity and uncertainty involved in the software development process.

Commitment

This is the promise to deliver functionality at a certain level of quality by a certain date. The really critical thing here is to realize that estimates inform commitments. But a commitment cannot and should never drive the estimate. The working position should be that the estimate is flawed and commitments have to be based on the most pessimistic estimate maybe even building in more fat. If the estimate is not palatable then business stakeholders should actually do the job they are tasked with and make the hard choices of prioritizing what is truly needed in order to give the project a quantified chance of success.

Too often in corporate environments existing commitments are made even before a project is understood or a project team has even been formed. Unfortunately this is done purely to look good and to make people feel better about their reality. Frequently this is done to mask incompetence and hide how poorly a portfolio is being managed. Regardless, the act of not basing commitments on tangible estimates might make stakeholders feel warm and fuzzy, but they are living a lie that will eventually catch up with them. Sadly most of the time stakeholders will consequently blame delivery teams for failures, never their bad decisions.

“If you are trying to make a commitment that is palatable instead of based in what is the best version of reality (aka the estimate) you might as well sit in a boardroom talk about all your dreams and wishes (regardless of how realistic they are), high five each other and hit the bar to celebrate since that is all you are essentially doing.”

In summary, if you are trying to make a commitment that is palatable instead of based in what is the best version of reality (aka the estimate) you might as well sit in a boardroom talk about all your dreams and wishes (regardless of how realistic they are), high five each other and hit the bar to celebrate since that is all you are essentially doing.

Target

A target is a single-point hard deadline, usually driven by some business need. It is has absolutely no relationship to the estimate of how long a project will take. In a perfect world estimation would happen before planning. The team will then come up with commitments on realistic sets of features and the business will then set strategic business targets based on reality never on fiction.

Similar to commitments it happens too much that targets are already fixed before estimation is even done. Or estimates are done by people that are not actually involved with building the software.

The key thing here is that if the estimation is subsequently done properly, stakeholders have to have the maturity to accept that what is being asked might simply not be possible. However many act like spoiled children that refuse to accept that what they are demanding is not possible. Instead they choose to play the guilt card on the delivery team for not being willing to go above and beyond. They remain oblivious to the fact that they still get to go home every night to see their children and live their lives whilst their teams bleed.

“They remain oblivious to the fact that they still get to go home every night to see their children and live their lives whilst their teams bleed.”

Forcing engineering teams to commit to a date that is more palatable to the business might make stakeholders feel better about situations, but if it is not based in reality (most of the time) it will result in dramatic failures at a later stage. This is not what it means to be a responsible corporate leader and you certainly are not operating with the best interest of the organization at heart. Put simply causing chaos in the lives of your employees to make yourself feel better about things does not make you a good leader.

Tips for being better

Understand the difference between these three concepts and live them in your day-to-day life.
I understand that it is hard to face senior stakeholders and tell them that what they want is not possible, but as a leader that is your job. If you are not willing to act in the best interest of the team and organization by being truthful about situations it means that you are just pulling the wool over everyone’s eyes to cover your own faults.

Don’t give estimates on the spot.
A rudimentary functional breakdown and sizing exercise is already much more accurate than a thumb-suck gut feel. As soon as you communicate any date people will treat it as a commitment. So best be sure that it is based in reality.

Never ever give a single point estimate.
As explained an estimate should always indicate a likely range and should be treated as information and nothing more. It provides context for discussions about commitments and business targets.

An estimate range is allowed to be wide.
For some reason there is an obsession to make estimates as narrow as possible since people are actually really looking for a commitment. The range indicates uncertainty and the fact that it is wide is relevant information. It illustrates the amount of uncertainty that is present in the project and should form part of the discussion.

Estimates should constantly be revisited and updated.
As you progress in your project and figure out some of the uncertainty you should be adjusting and refining your estimates.

Us the most pessimistic estimate to inform business targets and commitments.
You are not doing anyone any favors by committing to unrealistic timelines because it makes you look better. It will fail and result in people blaming each other leading to resentment and a breakdown in trust.

Always ask whether people are looking for an estimate, commitment or target.
If expectations in conversations are clear so much of this dysfunction could be avoided.

The learned helplessness of corporate companies

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

Learned helplessness in corporate companies

It is really hard not to become despondent in bureaucratic organizations

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

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

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

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

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

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

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

Why technical leaders fail

“What matters more than solving every scenario perfectly is execution. The ability to get things done trumps generating endless ideas of how some knob in the complex malaise of people and process can be turned. “

Why technical leaders fail

Good software developer != Good leader. Why we stumble as technical leaders…

Of course there are plenty of other industries that are comprised of very highly educated clumped together behind a common goal, but few have such a low barrier to entry in terms of building complete products with a relative small amount of resources. Simply put few other industries offer the intellectual challenge of the endeavor and the ability to realize ideas and products almost in complete isolation.

Due to this low barrier of entry, software tends to attract true creators. At the heart of every coffee slurping geek, is someone that is in love with using his or her mind to create something from scratch. Someone that yearns for a better world. Someone that sees things not for what they are, but the potential of what they can be.

Yet software projects and start-ups have notoriously high failure rates. How can it be that an industry with so many bright and capable people fails so darn much at delivery results? More worrying is how often leaders that come from a technical background fail. Commonsense would have you think that someone that understands the ins and outs of the craft should exceed where more traditional leaders fail? Why is it that so many technical leaders struggle so much to adapt to their role? Why do great engineers make mediocre managers?

The heart of the problem lies in the fact that as an engineer you live in the world of ideas. You are used to exploring the recesses of every problem losing yourself in the world of solutions and efficient designs. You value micro optimization and doing things right. You strive to make each aspect of your code or algorithm as perfect as possible.

The problem is that leadership requires you to be a generalist that is obsessed with execution. There are so many facets to running a business that technical leaders always run the risk of getting lost in the world of ideas, in the process suffering analysis paralysis.

What matters more than solving every scenario perfectly is execution. The ability to get things done trumps generating endless ideas of how some knob in the complex malaise of people and process can be turned. The line between visionary and dogmatic is unfortunately a very fine one.

“Simply put, as a former technical leader if you find that you spend a lot of time talking about ‘the how’ of things instead of ‘the what’ of things you might still be caught in the mindset of a programmer trying to micro optimize every aspect of a system. “

Simply put, as a former technical leader if you find that you spend a lot of time talking about ‘the how’ of things instead of ‘the what’ of things you might still be caught in the mindset of a programmer trying to micro optimize every aspect of a system. Users don’t care about methodology, architecture, design, or technologies. They care about great products that solve their needs and make their lives better. Tune your actions to always doing the things that will yield the best possible product and you will quickly realize that micro optimization to that knob in your process will most of the time not yield a faster better product and is simply a distraction.

Never lose sight of this..

What it means to be a leader

“You have taken the complex interpersonal dynamic of natural leadership formation, ripped away many nuances and intricacies and put in place a sub-optimal model.”

You have to have the natural trust and belief of those you should be serving in order to achieve great things.

True leaders are servants to their people.

It is unfortunate that industrialization has left us these rigid organizational structures that make no sense in a knowledge economy. When you put a hierarchy in front of someone and start talking about career paths, drawing their attention to where in the chart they are, emphasizing all the ‘growth’ that is above them you are in the process dis-empowering them. You are telling them this is you over here, and these are the people above you. These lofty people are your superiors and have this supposed ‘power’ over you for reasons that may be authentically valid or more often frightfully contrived and engineered.

You have taken the complex interpersonal dynamic of natural leadership formation, ripped away many nuances and intricacies and put in place a sub-optimal model. In the process simplifying the complex human dynamic to a laughably simple system that only vaguely reflects the natural tribal dynamic of a group of people coming together.

Like any simplified model it only works for certain circumstances and frequently fails for others. So why does it persist? In order for it to work it requires people to perpetuate and belief in the model. It requires people to embrace and live the model without question. It requires people to embrace it, ignoring the obvious faults. It requires people to make it a taboo to question it. Unfortunately tying people’s compensation to the model means that most rational people will do exactly these things.

People will always do what is best for themselves, and since money has become a proxy for survival when this terrible game is laid bare most people will compromise themselves. They will go with the flow since not doing so will threaten the livelihood of themselves and their family. So it is that learned helplessness kicks in and people start playing the game against their better judgement. They redefine their reality to trying to figure out how to beat the rules of the system and move up this artificial hierarchy. They give up on how it should be and start believing that that they cannot change it.

This results in so many issues, many of which I am sure will get explored in the blog. But the one I want to explore in this post revolves around how it bastardizes leadership. Leadership gets conflated into this misrepresentation of how high in the chart you are and how many leaf nodes there are underneath you. Leadership gets implied based on how well you play the game, not on whether people trust you and want to follow you.

The truth is that true leadership has nothing to do with rank or power. True leaders are servants to their people. A more natural model would be to invert the frequent organizational diagram with the subordinates sitting on top of the leaders, since a true leader’s responsibility is not to serve themselves and their own ego but those of his or her people.

“The truth is that true leadership has nothing to do with rank or power. True leaders are servants to their people.”

You are only as effective as the people who support you, and if you are only in a position because of you managed to game an imperfectly structured contrived system you are very quickly going to find out how hard it is to do anything of real substance. You have to have the natural trust and belief of those you should be serving in order to achieve great things. And no title or rank in a hierarchy can create this.

The Obligatory ‘Hello World’

“The problem is compounded when former technologists move into leadership roles where their formerly invested technical skill-bases have to almost be completely abandoned in favor of the soft skills that are required to be an effective servant leader.”

The Obligatory ‘Hello World’

It is my goal to create a resource that other technologists on a leadership path can use to help survive the gauntlet of fire of self management training.

And so, a new blog is born. I always found the software industry to be a counter intuitive experience. The industry is riddled with introverts that came into the industry because they draw energy from themselves and their thoughts. Software development presents more than enough problems that allow us to engage our inner thoughts.

But most of us quickly learn that in order to build anything of substance you need to work with other people. In fact, the ability to communicate and collaborate with others in the industry ends up being one of the biggest success factors for a software professional’s career frequently determining how fast and far the person can progress.

The problem is compounded when former technologists move into leadership roles where their formerly invested technical skill-bases have to almost be completely abandoned in favor of the soft skills that are required to be an effective servant leader. To make things worst organizations typically are not geared to help these new leaders to develop these softer skills required for their new role leaving them to fend for themselves. Most organizations take this bizarre approach of running their best technologists through this gauntlet of leadership adaption fire in order to identify the few that somehow learn to adapt and survive. This exercise frequently comes at great cost to the ones that fail to transition to the new skill set both in self-esteem and motivation. It is not uncommon for those former great technologists to regress and redefine themselves elsewhere meaning that their former talents and skills get lost to the organization in the end.

To be one of the few that survive it is a hard, frustrating journey where most are left to learn through continual trial and error and vast stretches of self-doubt and criticism. This sink or swim approach to management training is one of the biggest disservices we can do for our people and is the theme of this blog.

It is my goal to create a resource that other technologists on a leadership path can use to help survive this gauntlet of fire. I am by no means an expert, but I do feel that if I document some of the learnings that it would help solidify them for myself and perhaps do some good in the long run.

Let’s see how it goes…