It’s a problem of what we have been taught, what we have learnt and how we think

When my generation went to school we were taught based on a mindset aligned with the industrial revolution.

We were taught based on hierarchies, the teachers and principals were at the top, we were at the bottom, we were subservient. We were taught how to do a task, told what to do and how to act, if we didn’t follow the rules we were “punished”. We sat at our little allocated desks, we were not allowed to get up and reform where we sat, what we did, or how we learnt. Our class size was between 20 and 30 people, that was the optimal size for a teacher and a school. We attended prepared lessons that were “given” to us (or often at us), we were not able to explore a subject in the way that suited our learning style best. Our learning was time-boxed, every lesson was 45 minutes or 1 hour and we were not allowed to explore the subject further, even if it was something we were passionate or excited about. We could of course do that in our “own time”.

We were taught based on a factory mindset, we were a cog in a big process wheel. The focus was on moving the learning widget from the left to the right.

Organisations formed before 2001 were formed and managed by people who were taught this way of working. They were taught to think this way and run organisations using this industrial mindset.

These organisations are based on hierarchies, success is when you get “promoted” up the corporate ladder, when you have more people “reporting” to you, when your “team” produces more widgets. Small change is done via projects and programmes, time-boxed windows in which a funding “bucket” is assigned and a “project team” formed to make that change. Once the time window or budget is exhausted the project is deemed a success and the project team disbanded, regardless if the desired outcome was achieved or not. Large change is done via “transformation”, larger time-boxed windows and larger transformation budgets are assigned. Multiple work streams are formed with a larger number of people who are aligned to move the organisation from its current sluggish state to a beautiful nimble butterfly. Often the transformation team are cocooned offsite into a separate building where they have lots of bean bags, movable whiteboards and colourful posters so they can “do agile”.

Unlearning this industrial mindset we have been taught is hard.

In the new generation of education young people are taught with what can be called an agile mindset.

Their teachers are there to help them gain new knowledge and learn new skills, the teachers behave like servant leaders and coaches. Young people form into small groups to learn and work on particular subjects, when the subject changes they will reform into different groups. They are free to roam the room and form spaces that they want to work and learn in, these spaces are like their groups, constantly reforming as required and desired. Groups are less than 9, this is the optimal size for collaboration and interaction. Often there are multiple teachers available to support the larger group, they are available when needed and observe when not. If a subject excites, a person can spend more time learning it to increase their knowledge and skills (within reason, exo skeletons still exist), if it doesn’t they can learn the basics and move on. Learning groups comprise people of different ages, the older people learning the skills of mentoring and coaching the younger people.

Organisations formed after 2001 were formed and are led by people who were taught this agile mindset. They constantly explore and experiment with this way of working as part of their culture and Ways of Working.

These organisations are based on flat structures, success is based on delivering outcomes which add value to their customers and therefore to their organisation. Small change is constant, teams are empowered to inspect and adapt their ways of working, They test ideas when they see fit and if the change has value they adapt their Way of Working to include that change. They only keep the changes that have shown value, they are not afraid to dispose of work that failed to make a valuable impact. Teams break the changes down into small iterations or experiments by default, and change is never seen as finished. Large change is done by the same teams but triggered when a macro event happens that requires change to be coordinated across the wider organisation. The coordinated change trigger might be a start-up entering a phase of hyper growth, the organisation entering a new market or product line, the organisation growing in the number of people who work there so that the current team topologies and Ways of Working are no longer effective, or a new threat from a digital native organisation who are looking to take market share. Teams work the way they always have, but an extra level of coordination is introduced to help coordinate this phase. This coordination is managed by defining and communicating shared goals across the organisation, often using the OKRs, and letting the teams decide how they will achieve those goals. The teams work in the same place they have always worked, removing any disruption or waste. Their work is still visible, dependencies are lightly coupled and visibility of a team’s work reduces the friction that often occurs when multiple teams need to collaborate to get a job done. They continue to do the work in a way that has been proven to work as they are already “being agile”.

Using and iterating this agile mindset is still hard, but not as hard as unlearning and relearning a new set of behaviours.

When we think of successful companies founded with the agile mindset, we think of Google, Airbnb, Uber, Valve etc. When we look inside those organisations we don’t see the adoption of agile frameworks and methodologies. There is no discussion about the use of Scrum or SaFe, there is just an agile mindset and the process of constant inspection, experimentation and adaptation. When we think of traditional organisations founded with the industrial mindset and who have joined the world of agile theatre, we see the wide scale adoption of agile frameworks and methodologies to “do agile”. We see the implementation of agile rules to be followed, and the retention of a hierarchy of roles and responsibilities. We see little inspection, experimentation and adaptation.

The agile mindset is different to the industrial mindset. Mindsets are hard to describe and even harder to adapt and change.

Agile Mindset

When asking an agile practitioner, expert or coach for a one sentence answer to “what is agile” you will often get the response “agile is a mindset”. When you ask the follow on question of “what is an agile mindset”, more often than not you will get an answer that is along the lines of “it is hard to explain but you will know it when you see it”

If you google search for the definition of an agile mindset you will get a variety of results.

“An agile mindset focuses on “being agile” as a foundation for success in “doing agile.” It is defined by the four values and described by the twelve principles of the Agile Manifesto and then manifested through an unlimited number of practices and different ways of working.” ICAgile

“An agile mindset is the set of attitudes supporting an agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change. This mindset is necessary to cultivate high-performing teams, who in turn deliver amazing value for their customers.” Susan McIntosh – InfoQ

Interestingly we could not find the term “agile mindset” in any of the early published agile content which is widely recognised as founding the agile movement.

You will often see statements similar to:

“A growth mindset is synonymous with an agile mindset” – ICAgile

Where the agile mindset is directly related to the growth mindset.

Growth vs Fixed Mindset

Dr. Carol Dweck published the book Mindset: The New Psychology of Success in 2006 and describes two mindsets, a fixed mindset and a growth mindset.

Fixed mindset

“This could be viewed as a traditional mindset, whereby people stick to what they know best, opting for familiar paths rather than investigating new opportunities. Obstacles or challenges are avoided at all costs. A fixed mindset essentially means people have a predetermined view of the world and are unwilling to change it”

Growth Mindset

“This is the essence of the Agile mindset. People with a growth mindset are open to new ideas and different ways of doing things. They do not run from a challenge — they persevere and think outside the box to develop a solution. Setbacks are not viewed as failures; rather, they are an opportunity to learn something new.”

Graphic is adapted by Nigel Holmes from the book Mindset: The New Psychology of Success by Carol S Dweck PhD.

“In the fixed mindset, everything is about the outcome. If you fail—or if you’re not the best—it’s all been wasted. The growth mindset allows people to value what they’re doing regardless of the outcome . They’re tackling problems, charting new courses, working on important issues.”

“Many growth-minded people didn’t even plan to go to the top. They got there as a result of doing what they love. It’s ironic: The top is where the fixed-mindset people hunger to be, but it’s where many growth-minded people arrive as a by-product of their enthusiasm for what they do.”

It is common to see the description of the agile mindset being connected with the growth mindset described by Dweck. It embodies the belief in the ability to inspect, learn and adapt.

Another common theme is to see the description of the agile mindset being connected with the published Agile Software Development Manifesto Values and Principles.

“Really, agile is a mindset — it’s a way of thinking — that’s defined by four values, described by twelve principles, and then manifested through an unlimited number of practices or different ways of working. It’s simply a deep understanding and culture of learning and experimentation and trying things out. Any creative work will benefit from this notion of an agile way of working.” Ahmed Sidky

Diagram is adapted from the Agile Mindset diagram by Ahmed Sidky and ICAgile

Agile Manifesto

Manifestos

“A manifesto is a published declaration of the intentions, motives, or views of the issuer, be it an individual, group, political party or government. A manifesto usually accepts a previously published opinion or public consensus or promotes a new idea with prescriptive notions for carrying out changes the author believes should be made.” Wikipedia

Manifesto for Agile Software Development

The Manifesto for Agile Software Development is widely accepted as the founding document for modern agile ways of working and is often just referred to as the Agile Manifesto.

“On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

Now, a bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants. The only concern with the term agile came from Martin Fowler (a Brit for those who don’t know him) who allowed that most Americans didn’t know how to pronounce the word ‘agile’.

Alistair Cockburn’s initial concerns reflected the early thoughts of many participants. “I personally didn’t expect that this particular group of agilites to ever agree on anything substantive.” But his post-meeting feelings were also shared, “Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. I was surprised that the others appeared equally delighted by the final phrasing. So we did agree on something substantive.”

Naming ourselves “The Agile Alliance,” this group of independent thinkers about software development, and sometimes competitors to each other, agreed on the Manifesto for Agile Software Development displayed on the title page of this web site.” – Agile Manifesto

You can read the rest of the history of the Agile Manifesto here: https://agilemanifesto.org/history.html

The Agile Manifesto was created by 17 people who came together from a wide range of disciplines that were founded in the Agile Mindset, well before the Agile Manifesto was created. This included:

Extreme Programming (XP)
SCRUM
DSDM
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming

Agile Software Development Manifesto Values

The founders of the Agile Manifesto defined four core values:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.” – Agile Manifesto

AgileData Values

The values above are based on the delivery of software applications, not the delivery of data or information. If we were going to iterate these with the data domain in mind we would end up with:

“We are uncovering better ways of delivering data and information by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Valuable data and information over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.” – AgileData Manifesto

Principles

“a comprehensive and fundamental law, doctrine, or assumption”

“A principle is a proposition or value that is a guide for behaviour or evaluation. In law, it is a rule that has to be or usually is to be followed. It can be desirably followed, or it can be an inevitable consequence of something, such as the laws observed in nature or the way that a system is constructed. The principles of such a system are understood by its users as the essential characteristics of the system, or reflecting system’s designed purpose, and the effective operation or use of which would be impossible if any one of the principles was to be ignored.”

https://en.wikipedia.org/wiki/Principle

https://digitalcommons.law.ggu.edu/cgi/viewcontent.cgi?article=1001&context=annlsurvey

Agile Software Development Manifesto Principles

As well describing four core values as part of the Agile Manifesto the founders also describe twelve core principles:

“We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” – Agile Manifesto

AgileData Principles

Principles form one element in a structured set of ideas that collectively define

and guide the organisation and the AgileData teams, from values through to actions and results.

We can take the Agile Manifesto Principles and change wherever we see “Software” to “Data and Information” like we did with the Agile Manifesto values. These are a good set of principles to define the agile part of the AgileData Ways of Working. We then need to augment them with a set of relevant principles from the product and data domains.