The Importance of Mindset

July 26, 2011 — Posted by Al Shalloway

I have been doing Agile for over a decade. During this time, I have seen many different ways of thinking about what Agile is. One way is to think that there is only one kind of Agile and that there is a large collection of methods to choose from as you feel appropriate. Another way is to realize that there are many different mindsets in the Agile community and that these mindsets are what give rise to the different methods.

What is a mindset? Wikipedia says a mindset is "a set of assumptions, methods or notations held by one or more people or groups of people which is so established that it creates a powerful incentive within these people or groups to continue to adopt or accept prior behaviors, choices, or tools. This phenomenon of cognitive bias is also sometimes described as mental inertia, 'groupthink', or a 'paradigm', and it is often difficult to counteract its effects upon analysis and decision making processes."

Speaking of paradigms, Wikipedia notes, "the historian of science Thomas Kuhn gave paradigm its contemporary meaning when he adopted the word to refer to the set of practices that define a scientific discipline at any particular period of time. Kuhn himself came to prefer the terms exemplar and normal science, which have more precise philosophical meanings. However in his book The Structure of Scientific Revolutions Kuhn defines a scientific paradigm as:

  • what is to be observed and scrutinized
  • the kind of questions that are supposed to be asked and probed for answers in relation to this subject
  • how these questions are to be structured
  • how the results of scientific investigations should be interpreted"

Think about these definitions for a moment. These are what focus our perceptions and our thoughts, what filter what we see and think. And, unfortunately, we rarely question them. We assume what we see and think is just the way things are. And that is limiting. Not bad, necessarily: we have to use them or we would be overwhelmed with information. But certainly limiting.

But the scientific tradition requires us to question our mindsets and paradigms. We must reflect on them from time to time to ensure that the one we work out of is helping us, not hindering us. Mindsets must be used and continuously challenged.

That is how new and useful paradigms come to be.

Flavors of Agile mindsets

Agile is a new paradigm. Before the Agile movement, the prevailing belief was that you needed to do a complete analysis of what you wanted to build and that developing a full, detailed plan before staring to design, code and test was the best way to ensure achieving your goal.

The Agile movement made different assumptions and took a different approach. You might say it started from a different system of beliefs. The Agile Manifesto was a declaration of a new belief system. It basically stated that people, software, collaboration and responsiveness are more important than process, documentation, contracts and following plans.

This manifesto is one set of beliefs and has led to one popular flavor of Agile. There are others that lead to other flavors of Agile. In May, I wrote a tongue-in-cheek blog post called The Lean-Kanban Manifesto where I pointed out some of these differences in belief systems. Here are some of the differences in belief that lead to different approaches:

  • favoring explicit conversations vs. intuitive abilities
  • favoring small steps vs. big changes
  • favoring quality systems vs. heroic individuals
  • favoring principles that guide our understanding vs. practices in which we must trust

The biggest divide is over the notion of defining process. I have run across many consultants that believe that attempting to define any process is folly. They reason that defined processes are intended to be followed and that in a non-deterministic system this leads to ineffectiveness. They view software development process as a complex-adaptive-system and therefore little cause and affect can be found. 

I believe there are two failures of logic taking place here.  The first is a fundamental misinterpretation of the relationship between determinism, predictability and degree of definition of a process. For example, lack of determinism does not mean lack of predictability.  There is a distinction between micro and macro-predictability. For example, a roulette table is not predictable at a micro level (you don’t know if the next spin will be black, red or green), but at a macro level it is clear that more money will be staying at the casino than leaves! For more on this, read the interchange I had with Don Reinertsen in the blog post, Types of Processes – by Don Reinertsen.

The other misunderstanding is the belief that a defined process is something to be followed.  Actually, having explicit conversations about one’s process is not to make it something to follow but to make it so people understand what each other is doing.  This is a mindset shift in and of itself – process is not to be followed but to facilitate understanding.

There are other divides based on belief systems. For example,

  • Most in the classic Scrum camp believe in starting with pilot projects. Most in the Lean-Kanban camp believe starting with the big picture in mind, even if a pilot initiates the process, is a better approach.
  • When it comes to transitioning to an Agile approach, Scrum thought leaders suggest changing the organization to fit the Scrum framework, that success comes in adopting a proven framework. The Lean-Kanban camp doesn't necessarily disagree that doing so would work, they suggest that doing so is often extremely difficult and that there are easier ways – both financially and emotionally on the people involved. Lean-Kanban suggests starting where you are and managing your rate of change, you can create just as much, or more, sustainable change with less cost and with less time.

It is more than just picking a set of tools. Beliefs lead to very different alternate behaviors. One must be aware of one's paradigms so they can both question them, learn better ones, and see when they apply.

My own paradigm shifts over the years

I wrote this blog post because I felt it was an essential component to understand a blog I about to write: "The Three Types of Scrum: Classic Scrum, Scrum with Lean practices, 2nd Generation Scrum."

I thought it would be helpful if I listed some of the paradigm shifts I've had over the last 30 years or so. Not saying these are the right ones, just giving them as examples to assist people in looking at their own paradigms. Most of these paradigm shifts are related to business but I have thrown in a few personal ones as well. (Times are approximate.) While at first glance, all of these may not seem fundamental, if you reflect on how believing the statements below affect my thinking, you can see they are all significant.


The voice in my head is not me (and if you said – I don't have such a voice, I mean that voice)


Most people are responding to past events that have been imprinted on them – so although they will give you current reasons, they are really being driven by their past


Errors are mostly due to the way one is working than due to one-off mistakes. Therefore, it is important to look at the way one approaches problems to see how to improve one's results


Most people (90%+) will do good work if you put them in good environments – conversely, most people will work considerably poorer when put in poor environments. Therefore, it is critical to work on the environments people are in rather than the people themselves.


Our thoughts and body are very connected to each other. Our minds and bodies are not separate.


People have different ways of absorbing information. How the mind works is reflected in the body (a la NLP).


People have different approaches to work and communication. Being quiet in some situations will mean 'yes' to some and 'no' to others.


People have comfort zones. They will become very uncomfortable if things change too quickly in either a bad or good direction.


Design problems should be solved from a top down point of view using patterns as operators that define the problem space (essentially Chris Alexander's approach to design).


People have different learning styles.


Incremental building of your software is useful.


Building things with time boxes is better than building things by scope.


Not all software problems are caused by the development people – very often the problems that show up in the development teams are caused elsewhere.


Customers know enough for developers to start writing – by asking customers to tell us all they know prompts them to reveal things that they don't know for sure.


Deming and Lean can be applied to software by looking at the principles underneath them both


While scrum is great at a team level, it does not give us enough guidance to significantly help solve organizational wide issues.


Lean in software is more about managing flow than it is about eliminating waste.

2009  Certain types of delays (mostly between getting and using info, making an error and detecting it) actually induces waste.  It is more important to avoid the creation of waste in software development than it is to eliminate it.


Explicit policies will greatly accelerate learning


The Cynefin framework helps one figure out how to work with people. It should not be construed as meaning one cannot take a systems thinking approach to people


Alan Shalloway

CEO, Net Objectives



Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban