The "Technical Triangle" of Effort Distribution

"The TQB Iron Triangle" has long since been overhauled. Still, there is a tradeoff that we need to make - and we all do this, every day. Unconsciously. The Effort Distribution Triangle is one way to bring the tradeoffs we make into visibility, so we can have a meaningful discussion whether we're making the right choices.

The Model

The label indicates "We aren't investing into it" and the opposing line indicates "Everything invested into resolving this".
The normal condition would be somewhere in the middle.

We have 100% of our effort to distribute. We can invest it any way we choose into delivering features, improving technology and discussion about goals and methods.
Regardless of how we distribute our effort, 100% is 100% - so choose wisely!

Opportunity Cost

By delivering features that might add value to our product, we do what development teams are supposed to do: create tangible business value. We always need to keep sight of business value, as this is the purpose of doing development work.

At the same time, excessive focus on delivery might cause us to neglect the underlying technology or communication.
In turn, the risk we run by spending too much time aligning and optimizing our technology is the time we lose on innovating and delivering things others need. This is our opportunity cost.

Technical Debt

Phrased positively, "Continuous attention to technical excellence and good design enhances agility."
It allows us to get more things done faster, and make changes with less effort.

Taking a pessimistic view, everything that isn't as good as technically possible can be called "technical debt". We always have technical debt, so at best we can control whether we consider the debt pressing or not.

Sometimes, we just want to get something through the door, and we're cutting corners on a technical level. We might have skipped the occasional refactoring, or anything like that.
Without accusation, I have observed many developers who prefer spending time on improving technology over time spent in meetings. While there are bad meetings, the consequence might be that some people don't understand things they should understand - communication debt!

Communication Debt

As mentioned in another article, "communication debt is the communications we should have had that we didn't have".
Good communication provides alignment, transparency and clarity of purpose. It's the basis for autonomy and self-organization within a company.

Communication takes time. Scrum, for example, dedicates five Dailies per week, plus one Planning, a Review and a Retrospective plus occasional Refinements - for a total of roughly 15% of your calendar to pure communication, and it's incredibly difficult to function as a team by going any lower. And that doesn't even include work floor communication, such as whiteboard design sessions, pair programming, code reviews and whatnotever.

Communication effort is an integral part of your total capacity to do things.

While some effort put into communication is in fact part of your ability to optimize both delivery and technology - there is also communication aside from that: Like letting other people know what you're doing, letting them learn from you or learning from them.

Make your choice

Take your pick anywhere on the triangle. Discuss the long-term consequences of this choice with your team. This choice is never once-for-all, you can always change it. Yet, there are choices of strategic nature and choices of tactical nature.
Strategically, a delicate balance is most suitable to maximize sustainability. Tactically, the team might decide to go all-in on technical improvements or feature delivery. That's not viable - so the Scrum Master and Product Owner should keep an eye that the triangle doesn't get too lopsided for a prolonged period of time.

Closing question

Who in your organization is making that choice for your team - and who is aware of the consequences of this choice?

Environmental influence on Planning

"How can we make an Iteration (Sprint) plan to deliver an Epic when we still have too many Unknowns?" - this question plagues many teams on their journey to agility. Let's explore!

Someone asked me this question, and I have observed a similar thing in other teams before. In a (formerly) Waterfall-Oriented environment, a developer claimed, "We can't tell you how much effort this is until we have the Specification document!" It's the same question, just in different form.

Environmental influence

There are so many environmental factors in here that contribute to the statement being a problem which needs to be solved that I am tempted to write an entire book about it. Without digging any deeper, here are just a few factors which hint that the initial question is merely the symptom of a more severe problem:

• Fear. For example, fearing the Unknown, fearing to not deliver, fearing to fail, fearing to disappoint - the stronger the fear element is, the more likely people will demand a reliable plan.
• Ambiguity intolerance. People or structures with low ambiguity tolerance prefer a bad plan, doing the wrong thing right over no plan and doing the right thing.
• Priority issues. If we're really working on the most important thing, the question isn't as much how long it takes as what is the best way forward.
• Alignment issues. An organization which expects teams to create reliable plans upfront, shouldn't be confronting developer teams with completely unknown topics just a few days before visible results are expected. 
• Slicing issues. There are always opportunities to deliver something based on an upfront plan and show some form of result, although the total amount of work required to get the expected final result doesn't decrease by putting more effort into creating thin slices.
• Scoping issues. An Epic that takes more than an Iteration can't be planned down to a Sprint. The best thing we can do is deliver a portion of the work.
• Push process. When stakeholders push work into the team and expect a specific result in a fixed time, we end up with the typical "Iron Triangle problem": Fixed time, fixed budget, fixed scope. What's left is a compromise on quality.

It should be the responsibility of management, ScrumMasters and coaches alike to create an organization where these issues aren't so relevant.

All that said, there's always the chance that something happened and we need a kind of solution quickly. In the first step, it's important to understand which of the above environmental constraints we have, and how strong or weak these are in relation to the team's work.

For example, if the fear factor is high on team side, we need to approach planning and delivery different from how we would if the main issue is unfamiliarity with slicing.

In my next article, I will explore some techniques in complete disregard of these external constraints that can help a team confronted with planning a completely unknown topic.

Want trust? Deal with fear!

"Fear is a bad advisor!" - proverb.
Positive working environments require trust. Trust can be given and earned - it can't be forced or demanded. Team building workshops often focus around building trust. Are they dealing with the symptom of distrust, though?

Here is a causal loop diagram modeling the relationship between trust and fear:

Red lines = dampening effect, blue line = strengthening effect. "=" sign = time delay

There is a direct relationship between trust and fear: Fearful people don't trust. Trustful people don't fear. Then, how do you get from A to B? It's not as easy as extending trust, although that helps.

The vicious circles

In the model, we see three different vicious circles which need to be broken almost simultaneously before trust can be established. I also hint a way to break these vicious circles.

Blame Games

Starting on the top left, the most visible fear cycle is related to Blame. Nobody likes to be blamed. Being afraid of blame, people hide their mistakes. in consequence either finding someone else to blame ("But you said ..." - "X told me...") or, when caught, receiving blame. Positive management must end blaming people. Blame helps nobody. Identifying someone responsible should never be aimed at having someone to blame, it should always be aimed at finding a way to change things for the better.
As coach, I have even resorted to the rather ridiculous tactic of saying "Ok, it's my fault. Now, how can you make sure it doesn't happen again?" - of course, it's ridiculous that it's my fault. That's not what matters. What matters is that the discussion about fault ends and we start talking change.

Coverups

The next vicious circle is related to information hiding. It's much harder to spot, as one can't know what one could know but doesn't know because it's being kept secret.
It takes a lot of sleuth work to put missing pieces together and discover where people are covering up inportant information revealing what is really going on. Why do people do this? Often, they either don't trust what will happen when uncomfortable facts are revealed - in which case it's a trust issue, or they know what will happen and don't like that - in which case it's a fear issue.
People wouldn't be afraid if failure was not perceived as a stigma with negative repercussions. Establishing a positive failure culture, "Hooray for failure" can go a long way. Just make sure that this Hooray is then hooked up with real learning and change - otherwise, a team member's trust in the team can turn into an outsider's distrust in the work of the team.

Choking Control

The third vicious circle is related to controls. Be that meetings, reports, supervision or checklists. While every single of these isn't necessarily bad, in sum, they can devastate people's ability to think, act and change. One control may be no issue, a hundred controls make it impossible to change anything - and simultaneously, often create a self-contradictory system where at least one control is always broken. People are constantly afraid of breaching control and spend more time on meeting control requirements than on doing actual work which helps the organization.
Managers stop trusting their employees when controls are broken, and employees stop trusting their managers when broken controls don't lead to more effective ways of working, but more controls. At worst, managers also stop trusting their controls when these prove ineffective and load yet more controls to control the controls.
Creating transparency what is truly going on and which processes are actually enforced by these controls can go a long way in abolishing their destructive force and minimizing control to truly helpful levels.

Conclusion

"Don't fear" or "We can trust one another" are hollow slogans. These don't help anything. "Building trust" without understanding the vicious circles and loopback dynamics leading to the low levels of trust we often observe in organizations.
The main lever for raising trust isn't simply building trust, but alleviating the fears which constantly chop at any small flower of trust sprouting up.

As coaches, we must understand both the fear dynamics and the fears driving people. Only then can we build the trustful environment needed to succeed.

Top 5 Ways Companies Hamstring their Development Process

Consulting with dozens of companies, I have come up with a list of the most common impediments that damage a company’s ability to generate maximal business value from development.

As profit goes down, companies are looking for ways to improve
- although the search is in vain unless root causes are dealt with!

“Business Value” is the positive business outcome of development (eg., Money earned, customer satisfaction, market share, conversion rate etc.), minus all costs of producing this outcome, including the delay incurred until gaining it, adverse side effects and opportunity cost of not doing something else instead. Or, in simpler terms, Business Value = success.

The following factors are commonplace, yet most companies are so oblivious to the damage these things cause that they might even be unwilling to deal with the issue:

#1 Communication

Regardless of whether it’s top/down, peer-to-peer, internal or customer facing - communication proves to be the #1 challenge in doing the most valuable thing.

Middle management filtering critical information, unsuitable use of media causes misunderstandings, waiting for responses causes unnecessary delay. Even then, not talking and acting upon assumptions often leads to the worst waste.

#2 Trust

Double-checking, approvals and permission processes as well as any other kind of control just keep people from doing that which helps the company most.

While something may always go wrong, a company built on the assumption that employees will purposely damage the business means you’ve lost already.

#3 Processes

Artificial process constraints lead to inefficiency in achieving results, oftentimes impose suboptimal solutions, are often associated with inherent waste, and might enforce unnecessary handovers.

Standardized processes are good for things where you don’t want to invest even a single minute into, yet development and its outcomes aren’t part of those.

#4 Structure

Inflexible organizational structures create indirection and dependencies, result in unavailability, reduce effectiveness, induce delays and limit the opportunities for value creation. Structural issues might reduce a developer's ability to deliver by a good 95%. As Deming said, "a bad system beats a good person 100% of the time".

#5 Saving money

Avoiding to spend money on that essential, "out of budget" component may result in a seemingly more inexpensive solution which may be a hundred times less efficient, potentially to the point where they might eat up the entire value proposal of the development effort.

Bottom line: money spent is irrelevant as long as that spending is below the value obtained. Keen spending goes a much longer way than vigilant budget maintenance.

Bonus: Consequences

#6 Artificial Dependencies

Closely related to communication, structure and trust, when people are forced to synchronize with others on topics they would have under control, the incurred communication overhead tranlates directly into reduced capacity, therefore a multiplicative factor in value reduction.
Such artificial dependencies might include non-value adding functions, such as reporting structures, centralized institutions such as "Enterprise Architecture", "Test Department" etc. As the proverb goes, "Make everything go over your desk and you are important."

#7 Lack of customer interaction

Low trust, bad communication or unsuitable processes, organizational distance etc result in an inability to deliver small increments. Every step taken without involving the customer directly is full risk of delivering zero value. This often produces a vicious circle where more and more risk is pushed downstream until all development happens without customer involvement, who is then usually disappointed to receive a worthless product.

Conclusion

Managers are continuously looking for better ways to get work done which allow them to keep the above things in place. Until we realize that the business relevant outcomes of the work are dependent on dealing with the above factors, all improvement initiatives will at best yield an efficiency increase without offering a better outcome.
Significant improvements in outcome fully depend on doing the right thing in the right way, and that means resolving the key issues around communication, trust, processes, structure and spending.

The IOWA-Number - a tool for team building

Not every person contributes equal amounts on the team, and that's often okay. But there are some cases, where a conversation is needed. I devised the IOWA Number as a tool to identify these cases.

Applying the tool

The IOWA Number can be used in the "Gather Data" stage of a Retrospective with the question: "How do you feel about your team members?" This does require a certain level of trust within the team to work properly, and be clear that the tool isn't meant to highlight people as problems, but much rather to help the team find itself properly. There is no score that's inherently good or bad, just some scores that will lead to further conversation down the road.
Most importantly, only apply the tool when you have a feeling that there are some outliers, as the tool is merely intended to open up a conversation on becoming better at collaborating!

Extremely low scores

In some, rare cases the team will feel that a person's absence will actually have a positive effect on outcome.
The most notable case of this happening is usually when said person is lacking so much knowledge that their questions disrupt the others' flow of work. A good way to strengthen the team would be to put delivery work a bit on the backburner and work intensely to bring the person back to speed.
Another common case would be that said person doesn't really understand the impact of their own way of working on the team, often due to being unfamiliar with others' self-organized ways of working.

In any case, team members with extremely low IOWA score need the team's support to rise to higher levels and the team should have an open conversation which behaviours are reducing IOWA score and which behaviours would increase it.

Moderate scores

Anything between 3 and 7 is usual. There's not much to discuss, unless there are tendencies towards an extreme. But since IOWA numbers are nothing more than a snapshot in time, it would be better to use the extreme value right away, as it doesn't make sense to defer a conversation.

Extremely high scores

There's no way to sugar-coat it, high IOWA scores are a risk, potentially even a threat to the team's sustainability!
People typically do not choose to have high IOWA score, they receive that score because they have superior understanding of a subject matter and a strong drive for action. Usually, they feel they are helping the team and the organization by working this way, and in fact - when it comes to getting stuff done, they help a lot.
Unfortunately, all of their help us unsustainable, as the team immediately falters when they aren't available and if for some reason, they should be out (e.g. sickness, family issues etc.) their absence could bring the entire team and whatever the team was working on to a standstill or collapse.

As I wrote in my book, "Extreme Agility", my suggested course of action would be to relieve the person from the responsibility of doing whatever they do so well and instead coach and support the rest of the team in this. It should be exceedingly clear that they aren't taken out of the delivering function because anything is wrong with them, but because they are needed as multiplicators in order to grow the team.

Conclusion

IOWA Numbers are a conversation starter when the team is on uneven footing. It's not intended to judge or condemn the work or contribution of any individual, much rather it is intended to bring people to a more equal footing in order to increase the team's sustainability.

In some cases, it may even be worthwhile to create IOWA Numbers for people in the team's close vicintity, such as traditional line managers. If this is done, be sure to include them in the Retrospective (which is rather unusual).

Continuous Deployment - more than a toolchain

A while ago, a prospective client approached me, "We've purchased a Continuous Deployment Toolchain, now we need someone to do the training." I was invited to meet the Head of Administration and an Admin team lead. 

Story Time.

Paying for vaporware

"Here is the toolchain we bought. We paid a six-figure amount for the strategy and a five-digit sum for the implementation. Now we need someone to train our Admins so that we can roll out the new process for all of our 500+ projects in the next Quarter."

I glanced at the Powerpoint slide.

If you think this is worth $100k, well ... I have a bridge to sell.

It's about culture!

I started asking: "Why the Admins? Wouldn't you much rather want to train the developers?"
I learned that this project was spearheaded by the Head of Administration and they didn't want the Head of Development to take credit for their idea. Plus, the introduction of Continuous Deployment (CD) was mainly supposed to relieve the efforts of the Admins.
Taking note, I asked: "So how did you come about this project in the first place?" In painstaking detail, the Admin team lead explained that the process of getting a release through the door often took months - and CD, automating the entire ordeal, would cut it down to minutes and free their time for much more important things.
Nodding, I probed: "So, the developers will check the code into git?" - "At the moment, they either send us the code via email or put it onto a Shared Folder." Remember - this was a good decade into the 21st century! "And then?" - "We manually compile the sources. In some cases, we've created some scripts to ease the job, but those scripts are brittle and fail with every new release." - "Have you considered giving the job of creating maven builds to the developers?" - "That's not their responsibility. We can't guarantee for the correct installation of the software any more if we let them do it."

Next icon. "What's Sonar supposed to do in this construct?" - "Check the code quality." - "Do you have code conventions or unit tests?" - "Neither." - "And who is going to do that job?" - "That would be the Offshore Testing Department."

This was getting more intriguing by the minute. "Are the Developers trained in the use of Ansible and Docker?" Shaking heads, "We will provide standard scripts and containers for others to use." Probing deeper, "How do you know which Ansible Configurations and Docker Images will be needed?" - "We will just create those which replicate our current environments." - "Are your Admins trained with either tool?". A smile, they figured that finally, I was coming to understand them: "That's why we need you."

"Just one last question, how are the tests going to execute?" - "If you look closely, after a Docker Container is created, it will automatically be deployed to the Test Stage for Manual Testing."


This was going to be an interesting ordeal.

Get ready for Continuous Deployment!

I devised a strategy and proposed the following approach:

1. Basic Leadership training for beginning agile transformations
2. Process Redesign Workshop to reconsider the current build process and responsibilities
3. Start a Cross-Functional Team from across all departments to integrate the CD pipeline on one project in the next quarter.
4. Coach this team in fundamental Software Craftsmanship - including Pairing, Test Automation and CI.
5. Use the pilot team to set up meaningful quality metrics and create a working build pipeline.
6. Involve others in the learning and gradually move towards cross-functional teams with e2e responsibility.

I was informed that my offer was probably a misunderstanding. I replied, politely, "If you ever choose to look deeper into this offer, feel free to reach out." They never did.

tl;dr:
The toolchain is irrelevant until you have the culture and structure in place. CD isn't something that a single department in a silo organization can do all by themselves. Instead of architecting the entire pipeline upfront, experiment, discover what works - what helps - and what is actually being used!

If you seriously intend to move towards CD, the long journey and steep learning curve really pay off once the peak is climbed.
One disclaimer, though: There's no guarantee that you can keep any of your current processes, structures and mindset.

Five signs you've got the wrong agile coach

You've set out to begin your organization's "Agile Transformation" and, lacking the expertise, you've brought in external consultants and/or coaches to make the endeavour successful. But since you're not agile yet, how do you know whether you have the right people on board?
Here are a few pointers that will help you identify rotten eggs - i.e. you can be almost certain that after the consultants leave, the show will be over, and best case you've only wasted money for nothing.

#1 - Lack of Battle Scars

Having the seniority to assist another organization in their agile transformation, the coach should have a lot of war stories to tell. Stories of experiments, pitfalls, troubles, joyful moments and cheerful victories. Stories of what they have experienced firsthand (not hearsay!).
What people tried, what they set out and where they landed - the differences between intent and destination, the obstacles and dangers on the journey - the small nudges that made the difference and so on.

If you see that the coach either has little to say from personal experience or is only quoting others ("double-hearsay"), beware!

#2 - A shelf full of solutions

It doesn't matter what your problem is, they already have the bottled solution ready! Just follow their advice, and you will become Agile. NOT!

Especially when they promote solutions as a silver bullet, i.e. universally applicable without concerns for context - you're in for trouble.

#3 - Change without change

Following pre-concocted agendas, outlining the change on fancy slide decks without ever talking to the people doing the actual work or knowing the real struggles they have isn't going to work.
The first three questions I would expect to ask: "Why would you want to become Agile?", "What will be different in a year?" and "What have you tried so far?".
If there are no comprehensible answers to these three questions: what exactly do you expect as a result?

#4 - Not rocking the boat

Many experienced consultants have learned to avoid challenging status quo and messing with people in positions of power. This is a great approach to maximize the amount of billable hours and to please those who decide whether their contract will be renewed.
As attributed to Einstein, "Problems can not be solved with the same mindset that created them.", it's essential to rock the boat - to identify and tell people about the root cause assumptions which lead to the problems that an agile transformation is supposed to solve. And if key decision makers aren't aware how they are contributing to the problem - how would they know what they must change to solve it?

Consultants who only compliments senior management aren't going to make an impact.

#5 - We've got this!

Probably the killer criterion for spotting fake coaches: They can do it by themselves! They have so much experience and expertise that whatever is brought to them, they have the right answer. Senior management doesn't need to involve at all, because the coach knows how to handle everything. Teams don't need to worry, because the coach will teach them everything they need to know.

The coach who offers the solution without teaching you how to find your own solution - doesn't help you learn, and if you don't become a learning organization, you're not going to be agile.

Conclusion

I would like to conclude with my favorite TheraminTrees quote, "People who don't want you to think are never your friends!"

A "coach" who doesn't make you think and challenge how you think - is the wrong coach.


Sour aftertaste? 
Let's fix this: Here are ten signs you might just have found the right coach!

Eight character traits of good leaders

Many people like to be in a position of leadership - without ever considering what makes the character of a leader. In this article, I propose a list of eight character traits portraying good leaders, regardless of position, rank or role.

"Leadership" - image courtesy of @danielmassoud4 taken from twenty20.com

Earnest

We acknowledge and respect people who walk the talk, who do what they say, who have and convey a clear purpose and work towards that purpose themselves.
Nobody would waste time with a hypocrite or someone who themselves doesn't know what they want or where they are headed. Good leaders spend a great deal of time considering what they want to accomplish and why - and their very being encourages others to join in.

Diligent

We natually have a tendency to commend diligent people. Those who are pay the necessary attention to detail while still having a clear direction tend to be successful and a pattern for those around them.
It's often the small things that become the downfall of people in position in power - so great leaders take care not to get stumbled over small rocks.

Perseverant

People who are willing to go the extra mile for what they believe in serve as positive examples. Few can shrug off a setback and march forward with unwavering zeal - so those who do will eventually rake in successes that are the result of harsh failure learning. Like this, they become exemplary even to those who never knew about the troubles along the road.

Bold

When you firmly believe in what you do, you're unashamed and unafraid to act and speak. Even when we disagree, we still notice and acknowledge those who are bold to take a step, expose themselves and their ideas to a broader audience and are willing to take the heat and fire of criticism and resistance.

Altruistic

People look for those that do something for everyone, maybe even for others. On the other hand, we disdain those who selfishly try to fill their own coffers and get out of the line of fire. Because of this, we admire those all the more who put themselves out of the center of attention and put the social benefit of their ideas and goals first.

Considerate

Everyone has different needs and different perspectives. We like to be accepted where we are and how we are. While bad leaders express ruthlessness and recklessness, good leaders spend time to accomodate those around them, making them feel welcome and cherished. Being social creatures, we tend to flock around those who make us feel comfortable.

Thoughtful

"Measure twice, cut once" - when dealing with people, we often don't get a second chance, so it's best to spend time pondering how we and our actions affect those around us. We need to be watchful what we say and do - a single careless word can burn bridges. On the other hand, a nice word creates a positive atmosphere, a little support in times of need builds bridges and by moving from basic courtesy to full acknowledgement of others' circumstances, we become people who others enjoy being around.

Progressive

"We all are where we are" - yet, that's no reason to stay put. Nobody is perfect, but we need to move on. Commendable leaders aren't only good at being who they are, they're continuously improving upon themselves. That character quirk we noticed yesterday is a great opportunity to reflect on how we want to be - and what we can do to be even better people today. By not being stuck either with themselves, their ideas or the world around them, the best leaders continuously adapt themselves, their ideas and their environment to move forward.

Summary

Leadership isn't about position. It's about who you are - and no classroom training can make you a leader. Only you yourself can do that, and you must work on your character in order to be one. This is not a one-time act, it's a lifelong process: The day you stop working on your character is the day you have stopped leading.

What is a Scrum Master?

The question, "What is a Scrum Master?" may sound easy to answer - RTFM, the Scrum Guide has a very concise section. But when looking at what a Scrum Master really does, it becomes a profound topic in and of itself.

The narrow definition

The most narrow definition is that it's the one person on a single Scrum team making sure the Scrum Guide is being followed and the team successfully delivers on their Sprint Plan. Most people work in organizations that think of this narrow definition and also behave likewise.

For people looking to move into such a role, the best starting point is reading the Scrum Guide, getting a few books (such as Geoff Watts: Scrum Mastery) and a certificate or two (PSM-I from scrum.org or CSM from Scrum Alliance come to mind) then start job hunting and learning on the job.
Sticking with the narrow definition is not a very fulfilling job, as systemic impediments never get addressed.

The broad definition

The most broad definition is that it's a person coaching an organization on becoming more agile, challenging existing paradigms and opening the way to more flexibility, and this means individuals, teams and managers on every level - from intern all the way to senior executive.

People

When it comes to being a Scrum Master in a broader sense, then Scrum is maybe 5% of the picture. In fact, Scrum itself will become less and less important and - just like the Agile Manifesto states - people and their interactions will become prevalent.

Agile Frameworks

The first thing you will need to explore is the other agile frameworks, starting with the team-level ones such as Extreme Programming and Kanban - and getting yourself familiar with the organization-level ones such as SAFe (Scaled Agile Framework), Nexus, LeSS (Large-Scale Scrum), DAD (Disciplined Agile) and S@S (Scrum at Scale). Of course, that doesn't mean you will be using all of these - but you should have a sufficient understanding to comprehend where they are useful and what their limitations are.

Management

Having a bag of agile theory under your belt, you need to move into organizational design and management by reading publications from authors like Drucker, Deming, Crosby, Taguchi, Taylor etc - and learning to compare and recognize their models.

Psychology

You will also want to explore the field of psychology to understand how and why people tick the way they do. That's a vast field, where you might want to reach into behaviouristics and conditioning (Pavlov, Skinner), emotions (Ekman), basic needs (Maslov), negotiation models (Ury), transaction models (Berne), habits (Duhigg) and many others.

Philosophy

To round this off, you may want to gain a deeper understanding of philosophy, which also has a lot to offer, with the most notable things you may want to get being logic (assumptions, fallacies, mental models), axiology and epistymology.

Economics

As the subject of how wealth works - i.e., how value is created, consumed and transferred, there's a strong correlation towards making a company successful: you have to learn how decisions are made, why agents interact the way they do, and what are the driving forces of an economy (both local and global.)

It's not very useful to do all of this upfront, but continuing to learn while you're on the job and working to continuously increase your sphere of influence within the organization.

Summary

The Scrum Master is a very deep role which, when taken with a deep, serious learning attitude, has a lot to offer and provides a tremendous field for growth. If you put your heart into it, you will reach tremendous awareness of and influence on your surroundings.
Don't let people tell you that a Scrum Master is "just a team role". Great Scrum Masters can make a massive impact on their organizations.

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.

Rules in a structureless organization

A critical aspect for Structureless organizations is how they deal with rules. One might think, "As soon as humans need to deal with each other, we need rules". Yes and no. Let's explore how rules change as an organization becomes Structureless.

We will explore the topic by starting with an unstructured organization, then progress from there.

Unstructured rules

Martial law - Unstructured rules

Unstructured organizations have rudimentary rules, which are often simply made up on the spot, either ad hoc or post hoc. Rules mostly serve as a means to protect existing power structures, i.e. to beat others into submission and to exhibit superiority.
Rules are made exclusively by those who have power, and the rules serve them and their interests.

There is little mention of rules unless one is quoted or created to deal with a specific situation - and even then, the rule is hardly ever communicated to anyone beyond those involved. There is no examination whether these rules are consistent, conflicting or even make sense.

Most rules are arbitrary and wouldn't stand up to scrutiny, yet they never get challenged, as challenging them would equal challenging those who hold the power. The only people who will challenge rules are those higher up in the food chain, and only when it serves their purpose. This is usually not necessary, as further rules can be added at any point in time, as the lack of transparency around rules will already ensure that nobody realizes the conflict.

The following characteristics are symptomatic of "rules" in an unstructured organization:

1. Double Standards: Rules apply only to some groups. Others are exempt from the same rules for no transparent reason. For example, favorable rules apply only to those with power and unfavorable rules only to others.
2. Rules that don't solve problems: Rules serve more to shame those who have infringed upon them than to solve a real problem.
3. Post-hoc rulemaking: When a situation occurs that is unpleasant to someone in power, rules are set up post-fact as a smoke screen to deflect the blame.

Such rules will never be written down, as the mere prospect of doing so might end up in a lawsuit. Those in power will make sure that it stays like this.

Indirectly structured rules

Indirectly structured organizations do have rules - and lots of them!
There seems to be a rule for everything - and most of these rules are highly formalized. They are intended to prevent any potential misunderstanding.

Most rules serve as a means of avoiding the need to address the root cause of the problems which have surfaced in the past, and every action of people is encompassed by some form of rule. Similarly to unstructured organizations, there is little discussion around whether rules make sense or are even applicable.

When people are unsure what to do, they will either try to discover which rule needs to be applied, or will look to someone in charge to provide a rule. In fact, people will try to avoid situations where no existing rule can be applied, as this poses an undetermined challenge. People tend to be more concerned with keeping the rules they have than whether these rules make sense.

Rules in indirectly structured organizations serve a more noble purpose than those in an unstructured organization. There are actually two different purposes:

• Providing safety to those acting upon the rules that their actions are meeting prescribed standards.
• Providing a sense of reliability to those creating the rules that people will act predictably.

The most denominating characteristic of indirect structures is the separation of decision and execution: Those making a decision are not the same people as those acting upon that decision. The indirection is in full effect when people state, "If you want to know why - please ask that person!"

The following three items are symptomatic for rule-making in indirectly structured organizations:

1. Decision proposals: Instead of just doing the right thing, people need to prepare formal proporals with slide decks for managers to get approval for doing what they feel should be done.
2. Central Process Decisions: It's not the people doing the work deciding what the best way to do the work is, but some people who - for some reason - are believed to have some form of superior knowledge about this work. This often comes with a Process Management division defining SOP's.
3. Finger-Pointing: People would rather apply an inappropriate process than admit they are not aware of what needs to be done. They can point to someone who prescribed the process and will claim inaccountability for the consequences.

The rules in indirectly structured organizations are often religiously followed by people at lower levels of the organization, while people on the higher levels are hardly aware of their existence. 

Managers in indirectly structured organizations are often even aware of this problem, yet are unable to trace this back to the system they have created.

Directly structured rules

Directly structured organizations oddly have fewer rules than indirectly structured orgs!

Rules are less constraining and prohibitive than in an indirectly structured organization, as they are aimed more at clarifying structure, helping people organize themselves and getting things done than at stopping undue actions.

Rules serve everyone and no longer treat everyone equally unfair. Rules acknowledge context and provide guidance. Rather than abolishing the application of common sense as an indirectly structured organization would, they guide common sense decision making at every level. Unlike indirectly structured organization, inapplicable rules are scrutinized and reworked as needed.

Rules help people discover the most sensible course of action without being prescriptive on the course of action, permitting leeway for sensible choices. As the social and procedural context of the work might be dynamic, people need to be comfortable with discovering the best way to move forward. Rules would only be created when those doing the work are unable to produce a desirable result.

Rules in directly structured organizations serve an even more noble purpose than those in an indirectly structured organization. Rules are directed at:

• Providing a basis for mutually beneficial, positive collaboration.
• Providing consistency on a larger scale.
• Avoiding preventable fault, thereby providing psychological safety for those doing the work.

Direct structures align need and provision: Those who have the need are able to either resolve it by themselves or directly access those who can. Rule decisions are made by those who can see and affect the outcome of their choices. The most sensible form of rule making in a directly structured organization is by asking those at the receiving end of a rule which kind of rule makes most sense for them.

Characteristics of rules in a directly structured organization include:

• Alignement with business goals: Rules support the work, rather than impede it. Rules that contradict business goals will be revised.
• Scrutiny: Everyone may discuss rules, and this doesn't happen out of frustration, but to drive improvement. Rules that no longer serve their intended purpose might be abolished or changed.
• Consistency: Conflicting rules which would result in a stalemate get revised.

Rules in a directly structured organization clearly correlate purpose and outcome. It's not essential for people in areas unaffected by the rule to know about the rule - and when effects occur that are not intended by the rule, it will be subject to scrutiny.

Structureless rules

The weird part about rules in a structureless organization is that they don't seem to exist. This, however, would be a misunderstanding as rules actually do exist - except that they are usually implied rather than defined and people don't even feel the need to formalize them, as this formalization does not add any value.

In general, the need for rules decreases as mutual understanding and alignment increase - and the high levels of collaboration in a structureless settings foster these things. While the creation of collaborative bonds usually requires a clarification of mutual expectations, rules are often not very helpful, because they are created with a lot of ambiguity and therefore, often misdirected. Much more important than setting a rule is aligning on the intended outcome of collaboration and creating an environment where impediments are quickly addressed and resolved.

Formal rules in structureless organizations are usually externally imposed, such as laws. It goes without saying that structureless isn't anarchy - so such imposed rules need to be maintained. As they are not an intrinsic part of the organization, people will discuss these rules not in a setting on what to do with them, but on the easiest way to get along with them.

Because structureless organizations no longer care about the rules themselves, discussions aim at:

• Finding positive, effective ways of collaborating
• Aligning mutual perspectives, understanding and outcomes
• Resolving issues which might otherwise require rules.

Nonetheless, these are already implicit rules - the rules of getting along and communicating. Probably the most important implicit rule of a structureless organization is the "No Asshole Rule". It will never be mentioned, as the mere need to mention it already means that a problem occurred that should not exist.

Characteristics of the rules in a structureless organization include:

• Implicit: Probably the most important characteristic is their implicitness: Rules do not need to be formalized, because they are implied by interactions.
• Minimal: Since rules cause or hide problems, they are a "last resort", when all else failed.
• Ephemeral: Structureless organizations rely on being able to constantly change and adapt, so rules might simply disappear when their context disappeared.
• Local: Rules would only exist in a local setting, and there is no attempt trying to consider whether they could be generalized to a broader context, as if there was a need, it would pop up anyways.

Structureless organizations aren't about rules. They are about aligning, collaborating and moving forward. When considering, structureless organizations have a lot of implicit rules - potentially more than the explicit rules found in an indirectly structured setting. The big difference is that rather than being in a manual nobody has ever read, these rules live and are part of people's lives.

Summary

An unkeen observer might confuse structureless rules with unstructured rules - although the difference is immense! Whereas unstructured rules are makeshift constructs to preserve power, a structureless organization understands the advantages and disadvantages of formalization and has moved from the level of top-down exercise of power to mutual understanding.

Structures are created to minimize communication over rules, assuming that rules can be formalized in an unambiguous way. Structureless organizations acknowledge that communication is essential to move beyond a limited and superficial mutual understanding. Once the necessary communication over collaboration has happened, the need for formalization disappears. Hence, the rules become implicit rather than explicit.