The effect of new ideas on learning

"It's always good to learn something new" - or so the proverb goes. Let's examine whether this is true, and how to maximize the impact of our learning.

In this article, I will classify new ideas into two categories: growth beliefs and limiting beliefs.

How our beliefs affect our learning.

To keep this article short, I will make a claim that I'm not going to back up further: Whatever we learn is merely a new belief, a new concept we hold about reality.

Growth beliefs

A growth belief is an idea which accelerates our future learning. Adopting a growth belief has a sustained beneficial effect on our ability to understand the world. Growth beliefs tick off slowly by slightly broadening our horizon, allowing us to integrate new ideas faster. Thinking in networks, a growth belief is a belief where further beliefs can easily be attached to. The following illustration visualizes the idea:

Upon the growth belief, further ideas are built and can be adopted easier.
The growth belief acts as a sustainable basis for growth of ideas

Limiting beliefs

A limiting belief is an idea which inhibits our future learning. Adopting a limiting belief has a long-term negative effect on our ability to understand the world. Unfortunately, the danger of limiting beliefs is that in the short term, they might give a massive boost to our ability to understand certain things. Again, thinking in networks, a limiting belief has a strong connection to related ideas which are oftentimes adopted immediately - while at the same time, the limiting belief is inconsistent with other ideas which become harder to adopt:

The limited belief is closely related to similar ideas
 - and inconsistent with other ideas, which we then struggle with or reject. 

When conflicts between ideas arise, we usually reject the new idea based on the ideas we already hold. Subconsciously, we find reasons why the new idea is wrong - either by trying to prove how it is deficient, or by trying to prove how our current belief is "superior". We are no longer open to listen to the merit of the new idea, as long as the cost of adopting it feels higher than the cost of rejecting it.

Discernment

Unfortunately, there is no certain way to know upfront which beliefs are growth or limiting ideas. As a general rule of thumb, though: The easier an idea tries to explain a complex problem, the more likely it will turn out to be a limiting belief. Or, in more scientific terms: The level of explanatory power of an idea is directly related to our long-term understanding of reality. Beliefs which we hold despite low or no explanatory basis are most likely limiting and should be put under scrutiny.

When ideas with higher explanatory power conflict with ideas we already subscribe to, we should examine what really makes us believe the things we already do and potentially discard the ideas we already hold.

Conclusion

It's only good to learn new things if we can either understand where the things we learn inhibit us, or if we have a mindset of letting go of inhibitive ideas. The latter is extremely hard, as beliefs we have already adopted are often strongly related and make up what we see as "real" - so the best thing is to avoid the trap of adopting limited beliefs wherever we can spot them.

Another thing we need to understand: One person's growth belief might be another person's limiting belief, based on both where the person currently stands and what the person is looking for. When we discover ideas to be truly limiting, it may already be too late to discard them without rejecting a major portion of who we are.

So - be careful what "new things" you learn! It might cost you dearly, years in the future!

Thought Reform and Mind Control in the Agile Community

How do we know we're making progress towards a meaningful goal? Are we following a carrot on a stick - or even worse: are we being led astray in our attempts to become more agile?
Has the agile community gone too far in their attempts of making agility a lifestyle?

I feel the need to write this post because I recognized some patterns in the agile community which I know all too well from the years of my life I spent studying and discerning the phenomena of psychological abuse. 


But let me start from the beginning.

DISCLAIMER

This article isn't singling out anyone or pointing fingers.
It's not about calling, labelling or stigmatizing anyone.

 Instead, it is an invitation for each of us to think where we ourselves are heading with "Agile".
Are we shaping an aspirable future with our words and actions?

If you feel that this article is talking about you or anyone you know, ask yourself: "Why?"
Why are we seeing those behaviours in the agile community?

Dangerous Behaviour

In this section, I will examine a list of behaviours based on the four common domains of "Mind Control" - neither with a claim that some specific persons would do all of these nor with a claim that some of the can't also be found elsewhere, just with a note that these behaviours raise a red flag. For brevity's sake, I am going to limit this to central points that are most notable.

I. Mind Control

Behaviour Control

a) Major commitment

of time and/or money for indoctrination purposes.This is talking about stuff like requiring attendance at group events and the trainings required to climb up the pre-defined hierarchy.

b) Group Think

instead of individual expression of thought. Society grows by bringing completely new ideas to the marketplace of ideas, then examining these based on their merit, instead of their point of origin. Group think means that ideas contradicting the group's doctrine will be rejected even if they are true and useful.

c) Obedience and Punishment

to enforce compliance. Obedience to the group's rules is paramount to keep order, even if said order is detrimential to growth and learning. Punishment and the threat thereof is used to keep members obedient.

Information Control

a) Deception

taking many forms, from outright lying over hiding facts all the way to distorting unpleasantries in order to make them acceptable. It's pretty much the opposite of transparency.

b) Discourage dialogue

with people who are critical towards the organization and its goals, including outsiders, ex-members and dissenting current members.

c) Compartmentalization

of sources. Information provided by "members in good standing" is good, information provided by "others" is bad, especially when in conflict with the organization's goals.

Thought Control

a) Axiomatic Truth

of any statement proclaimed by the group. There must be no doubt that the official doctrine is true by definition.

a) Black vs. White

thinking. There is no ambiguity and no alternatives. If it isn't A, it is B. This provides the basis for simple explanations to life's complex problems.

c) Us vs. them

mentality: There is no sane reason not to be on "our" side: Everyone else isn't enlightened enough or has a problem.

d) Loaded Language

reducing complex topics to contrite buzzwords. This inhibits, rather than growing, a deeper understanding.

e) Forced positivism

where people may be branded or shunned for "negative thinking".

f) Thought stopping

techniques are applied to suppress the need for analysis, critical thinking or constructive criticism of the group's doctrine.

Emotional Control

a) Manipulating feelings

of people for or against people or ideas by using psychological or linguistic triggers.

b) Blame shifting

towards those expressing ideas inconsistent with the group. Nothing can ever be the group's fault, it must be those who see the problem. Also manifests as: "Shooting the messenger".

c) Use of fear

tactics to keep people silent and in line. This is also combines with:

d) Phobia induction

in current members. Something bad will happen if you follow other ideas, or, God forbid, decide to leave the group. And remember: there are no legitimate reasons to quit - ever!

II. Apologetics

Apologetics is a huge chapter in and of itself. Talented apologists have a massive arsenal at their disposal, with the main goal of silencing dissent. Apologists tactics range anywhere from "working the issue" towards character assassination. Again, for brevity's sake, I will reduce this to an examination to the three core tactics employed by apologists.

Logical fallacy

The largest category of weapons in the apologist's arsenal is the employment of logical fallacies. There are too many to discuss - it's really worth exploring this domain of philosophy to be less prone to manipulation, so we will limit this to the most notable ones.

a) "Misunderstood"

When caught on a contradiction, the first line of defense will be "Ah, you misunderstood". Can be well combined with Loaded Terminology ("join us to learn what we mean") and blame shifting ("YOU get it wrong!") Note that the apologist will do their best to avoid clarifying the real meaning, as this would put the burden of proof on them.

b) Moving the Goalpost

Another powerful bait is to move the topic away from items which can be scientifically examined and scrutinized by changing the meaning of things mid-discussion. Combines very well with Loaded Language ("It means something else") and axiomatic truth ("If it were wrong, we wouldn't say it").

c) Appeal to Authority

or to Popular Opinion. Instead of tangible evidence, names and titles ("Doctor X") or sweeping generalizations ("Everyone knows ...") are offered as "proof".

Making it personal

Instead of arguing or providing evidence about the matter, the person of the critic becomes the topic of discussion in an attempt to "shoot the messenger" to avoid that the message itself needs to be examined. This can range anywhere from:

a) Who are you?

It looks easy to discredit a person who doesn't have the combined experience of those one the other side of the argument by simply stating, "We have industry leaders, professors and scientists - and you are?" If this doesn't end the discussion, they will move on to:

b) Mud slinging

and shifting the dicussion towards personal shortcomings of the dissenter, either in tangible aspects ("You failed at ...") or even their alleged emotions ("Why do you have such anger/hate towards ...?")

c) Character assassination

by providing unsubstantiated reasons why listening to the person speaking the different idea is a bad idea, such as "The person is a fraud, a criminal, psychologically defective and you'll be damaged if you listen"

Shifting the burden of proof

What's more convenient than turning the entire discussion around - instead of "Why should I do X?", let the dissenter explain "Why do you not want to do it?", which allows the apologist to lean back while the critic has to waste time and energy, exposing their thinking and providing additional places of attack for the apologist.

Instead of digging deeper here, let me refer back to Hitchen's Razor: "That which is assumed without evidence may be dismissed without evidence." What this means: If someone claims that a certain thing works, you don't need to disprove that. They must prove that it does.

I also want to combine this with Sagan's Standard, "extraordinary claims require extraordinary evidence" - so the next time someone says that "this always works" or "it can be used in any context", remember: that's an extraordinary claim which still needs to be proven!

III. Change of character

Thought reform modifies people's character in ways that are detrimental to society as a whole. In order to avoid getting too personal to anyone, I will keep this section at short, commented headlines.

Situational ethics

Things which a normal person wouldn't do in normal circumstances are okay when it's required to protect the group's special interests or to further the group's declared mission. For example, being deceptive, outright lying or slandering outsiders.

Need for conversion

Once you believe your group has "The Truth", you want to do everyone a favour by converting them to your group. Rejection isn't taken lightly, as this attacks the very thing you believe in. "They" must be evil if "they" don't take your gracious offer.

Following leaders

The group's charismatic leader(s) offer "The Truth", so what comes out of their mouth must be good. Critical thinking is shut down when words are spoken by a leader. Members of thought reform movements just can't understand why other people wouldn't have the same level of veneration for their leader as they do.

Preoccupation

You don't have time to waste on things such as thinking or interacting with outsiders, as you need to do things which further the agenda of your group. After all, you have an important mission - and it can only be achieved if you're fully dedicated.

Mental shutters

You are no longer open to ideas that conflict with the group's ideology. Instead, you invest time into ideas that are "in party line".

Limited social interaction

You reject people who propose ideas that don't fit with the group - and break "dangerous" relationships, warning others about such "poisonous/toxic" people as well.

Sobriety

You don't understand a joke at the expense of your "truth". NOBODY is allowed to joke about the truth, and you will make sure that those who dare do so get put into place.

Concluding words

Thank you for continuing to this point. It is sad to see that even in the agile community, we see many people who are affected by such symptoms without even realizing. It's even sadder to see when people entrench themselves further in such limiting beliefs and behaviours day by day. Such behaviour is often the consequence of having too much vested interest in this entire Agile/Scrum thing and taking it a bit too far or too seriously.

I would leave you with a few open questions, that you may reflect for both you and those around you:

• Do you see positive growth in character caused by following an Agile career?
• Is there a willingness to discuss the option that there might be the slightest chance that all of it could be wrong?
• Are sound, factual reasons brought forth when contradicting ideas are raised?
• Is there respect and positive openness even towards those who hold conflicting beliefs?
• Are any detrimental behaviours developing, and what is being done about them? 

Five Things to avoid as Scrum Master

What makes a good Scrum Master, what makes a bad Scrum Master? Here is my short list of things a Scrum Master will not do in my team. This post is written from a Product Owner perspective, so YMMV.

#1 - Dogma

This has got to be the absolute #1 on my list as it is my personal pet peeve.
I don't care what this or that guru said about Scrum, and I don't even care what you think Scrum means. I'm not using Scrum for Scrum's sake. I care for stuff that works - and for fixing stuff that doesn't work. I've had too many conversations with certified ScrumMasters who claimed "According to Scrum ...", and my only response was: "Show me the passage in the Scrum Guide!" (knowing full well they were proliferating a myth). If you can't explain to me (or my team) why the things you think should be different would work better than what we're currently doing, you're wasting everyone's time.

#2 - Factions

Your job as a Scrum Master is to create one high-performing team, and that just won't work if the team is wasting energy fighting against others (or even worse, against each other). If factions exist, you should try to mend them - and if none exist, I would expect you to be the last person to create some. Factions often come with actions such as placing blame (aka. finger-pointing) or perceived feelings of superiority. I expect you to not tolerate, much less support any such behaviour.

#3 - Menial labour

Also known as the "Jira Admin". If your entire responsibility in the team boils down to doing the things nobody else wants to do, such as updating tickets, writing reports or organizing meetings, you have clearly not understood your role. As Scrum Master, your value is exclusively limited to the additional performance you bring out in the team. If you can get 5 people to work 50% more effective, you're pulling your weight. If, however, you're just doing work that a minimum wage worker could do after a week of training, don't expect a higher pay than minimum wage.

#4 - Breach of trust

As Scrum Master, I expect you to be the person in the team who has the highest level of trust from anyone within the entire organization. I would expect that people should feel ready to confine their innermost secrets to you, even stuff that's totally NSFW, because they might need someone to talk about it in order to have a clear head for work. If you do stuff like reporting to management or tell team internal information to outsiders, you will never again be able to regain the trust you need in order to do a proper job.

#5 - Project Management

I do agree that not every team is ready for self-organization and sometimes, an intermediary path needs to be taken. As Product Owner, the person who would be doing inevitable PM activity would be me. As Scrum Master, frankly, you don't even need to know more about the team's progress than I and the team feel necessary. There is no reason why you should feel the need to coordinate, organize or report anything for anyone. Well, unless you're being asked to - and even then, you should ask "Why?"

Conclusion

If I see you, my Scrum Master, doing any of the above things, you're up for a long conversation with me regarding your role and responsibility. You will walk out with a clear list of things that you will change about your own behaviour as soon as possible.
If I see you continuing these things against better knowledge, I will make sure that I get a Scrum Master on my team who knows their ropes.

The Agile / DevOps ecosystem

The question, "How does an organization, especially one that is already using an agile framework, benefit from DevOps?" is very common. In this article, I provide a succinct answer to this question by examining the benefits provided by some standard frameworks.

The development lifecycle

Irrespective of which approach a company is using, it all starts with a customer need:

This need must be understood, so we need to invest some effort into understanding.

In Scrum, we call this "Refinement". It could also be called an Ideation or Prototyping process. Regardless of how you call it - it's essential to build the right product!

Once understood, our next job is to build something. Any kind of iterative approach encourages us to build just a little, then learn from that. We want to minimize our upfront planning efforts and jump right into doing delivery work. In Scrum, that's our timeboxed "Sprint".

The objective of delivery is to get something shipped right to the customer, we want to make the product available. This is often called "Minimum Viable Product", in Scrum we call it the "Product Increment".

When we got the product out of the door, we want to learn how customers respond to it. This is where most agile implementations disconnect: Scrum has a "Review" - although the Review still happens disjoint of both the problems and opportunities arising when our product hits the shelves!
What happens in the "Real World" becomes the job of Support, Customer Service or Marketing.

This final piece of the puzzle is vital to build an even better product in the future. We want to iterate a full cycle in increments as small as possible:

The business opportunities when integrating this cycle are immense: Anything that is of value can be turned into revenue, anything that wastes effort can be turned into saving. To harness this potential, it's essential that a single team has the ability to recognize and create these benefits.

Now, it's time to take a closer look at some agile frameworks:

Standard frameworks

Scrum

Scrum is the most common framework. It excels as a delivery framework. Based on the Scrum Guide, it neither cares for what happens in order to get the right items into the Product Backlog nor what happens after the product increment has been delivered.
A small fly in the ointment is that Scrum scopes the timebox: it doesn't bode well for a Scrum team to deal with unplanned work. Yet, everything that happens with customers in real time is hardly planned, much less does it make sense to plan it upfront.

Kanban

Like it's cousin Scrum, Kanban focuses strongly on optimizing the delivery process. Kanban provides less emphasis on getting a planned shipment through the door, offering higher flexibility in dealing with unplanned work. Teams that have productive maintenance responsibility often fly well with Kanban.

Side note: Scaling Frameworks

Scrum scaling solutions, such as Nexus, Scrum At Scale (S@S), LeSS focus on doing the same thing with more people - getting better at delivery. Combining these frameworks with Enterprise Kanban practices, like suggested in SAFe, is still limited to the delivery portion.
While SAFe strongly encourages integrating DevOps, the suggested use of DevOps is still restricted to getting the product through the door in the most reliable fashion.

Design Thinking

It's often adertised that Design Thinking combines well with Scrum, and indeed it does. Design Thinking addresses understanding the customer need through systematic exploration before delving into a more costly delivery process.

Lean / Six Sigma 

Regardless of whether you're thinking Lean, Six Sigma, or the standard combination "Lean Six Sigma" - these frameworks address optimizing our existing product through better insight:

Extreme Programming

Returning to the agile hemisphere, Extreme Programming and some of its derivates, such as Programmer Anarchy, add more emphasis on understanding the customer and providing the right solution for the customer's needs.

DevOps

DevOps is concerned with two things: Getting the product to the customer with minimal overhead and delay - and understanding how the product is being used.
The first, and well-known, portion of DevOps is providing an automated delivery Infrastructure - Continuous Delivery, Infrastructure as Code, Containerization, Logging, Authentication and many other things come to mind.

In addition, DevOps, done well, provide a myriad of analytical insights into the product: which features are being used, how new features are being received, where unexpected things occur, how to solve customer issues etc. This requires more than technical insight - it requires harnessing business insight as well!

The big picture

DevOps is an essential piece of the puzzle towards hyperperformant teams. The full power of an agile team requires a smart combination of discovery and delivery methods. It's your choice whether your team sails under the Scrum, Kanban, XP, none or any other banner - just make sure you cover all of the blocks:

Design Thinking shines for the "Understanding customer needs". Scrum is great to cover the "Doing work on customer needs" section. Combine these two with DevOps to optimize your "Working on the available product - both before and after delivery" approach.
For best results, you might want to add a touch of Lean, an ounce of XP and a pinch of Kanban,

Closing the loop

Let's forget frameworks for a minute. What's important is that you got everything covered. Use Design Thinking where it helps you build a better product. Apply XP where it helps you build the product better. Try Scrum elements that improve your delivery process. Utilize DevOps tools and practices to ensure you're doing the right thing when the rubber hits the road. And never forget - Lean/Six Sigma has really powerful tools that help you do the right thing better!

If you look closely, you will discover that this cycle is an implied "Build-Measure-Learn" cycle, which is the core premise of Lean Startup, yet another framework from the agile bucket.

Closing remarks

No single framework, approach or method is sufficient to deal with the complexity of creating and maintaining a successful product. All frameworks have useful and important elements to offer. Combining them for best results is a core practice of agnostic agile practitioners.