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” (&&).

Advertisement

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.

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

Why technical leaders fail

“On the other end of the spectrum, leadership requires you to be a generalist who is obsessed with execution and good enoughs.”

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

As an industry, software is unique in that it attracts true creators. At the heart of every coffee-slurping geek is someone who is passionate about using their mind to create something from scratch. These individuals often yearn for a better world and see things not for what they are, but for the potential of what they could be.

Unfortunately, software projects and start-ups have notoriously high failure rates. This is particularly true for entrant leaders who were formerly technical. It seems counterintuitive that an industry with so many bright and capable people struggles to deliver results.

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.

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.

On the other end of the spectrum, leadership requires you to be a generalist who is obsessed with execution and good enoughs. There are so many facets to running a business that technical leaders often get lost in the world of ideas and suffer from 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 processes can be turned. The line between visionary and dogmatic is unfortunately a very fine one.

To be an effective leader, you need to be able to prioritize, delegate, and execute. You need to be able to balance the needs of your team, your customers, and your business. You need to be able to navigate the complexities of running a business and make tough decisions. And you need to be able to adapt and learn from your mistakes.

It is not easy to make the transition from an engineer to a leader. It requires a shift in mindset, a willingness to embrace new challenges, and the humility to ask for help when needed. But for those who are able to adapt, the rewards can be immense. As a leader, you have the opportunity to inspire and empower your team, to create something that truly makes a difference in the world, and to leave a lasting legacy.

What it means to be a leader

“Effective leadership requires the trust and belief of those being served. No title or rank in a hierarchy can create this..”

True leaders are servants to their people.

True leadership has nothing to do with rank or power. In fact, true leaders are servants to their people. The rigid, hierarchical structures that have been prevalent in organizations for so long make little sense in today’s knowledge economy. When we focus on hierarchical career paths and highlight the “growth” opportunities above us, we are disempowering individuals and simplifying the complex interpersonal dynamics of natural leadership formation.

This simplified model only works in certain circumstances, and often fails in others. For it to persist it requires people to perpetuate and believe in the model, embrace it without question, and make it taboo to question it. Unfortunately, tying people’s compensation to the model means that most people will do exactly that. They will compromise themselves in order to protect their own livelihoods and those of their families.

“True leadership has nothing to do with rank or power. In fact, true leaders are servants to their people.”

As a result, leadership becomes conflated with rank and power and is based on how well an individual plays the game, rather than on whether people trust and want to follow them. The truth is that true leadership has nothing to do with these things. A more natural model would be to invert the traditional organizational diagram, with subordinates on top of leaders, since a true leader’s responsibility is to serve their people, not themselves.

Effective leadership requires the trust and belief of those being served. No title or rank in a hierarchy can create this. True leaders are servants to their people, and their effectiveness is directly tied to the support and trust of those they serve. Without this natural trust and belief, it is impossible to achieve great things. And no amount of gaming an imperfectly structured, contrived system can replace it.

The Obligatory ‘Hello World’

“Unfortunately, many organizations are not equipped to help these new leaders develop these skills…”

It is my goal to create a resource that other technologists on a leadership path can use to help them navigate the challenging journey.

The software industry is often seen as a haven for introverts, as it provides ample opportunities for individuals to engage with their own thoughts and ideas. However, as many software professionals quickly learn, building anything of substance requires collaboration and communication with others. These “soft skills” can be critical for a software professional’s career, often determining how quickly and successfully they can progress.

The problem is compounded when former technologists move into leadership roles, where they must almost completely abandon their technical skills in favour of the “soft” skills required to be an effective leader. Unfortunately, many organizations are not equipped to help these new leaders develop these skills, leaving them to fend for themselves. This sink-or-swim approach to management training can be detrimental to both the individual and the organization, as it often leads to the loss of valuable talent and skills.

In this blog, I hope to create a resource for other technologists on a leadership path, to help them survive this difficult transition. I am not an expert, but I believe that documenting my own learnings can help me solidify them, and potentially benefit others. Let’s see how it goes…