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, 2^nd 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.

Alan Shalloway

CEO, Net Objectives

By TwitterButtons.com