Agility isn't for everyone!

A lot of conflict in the workplace is caused by different expectations regarding the nature of the work. And agilists may not even be helping - they might just make it worse!

Here's why:

The Stacey Matrix - annotated with character traits.

Character traits per domain

Simple work gives confidence to people who excel at tasks that others may consider "chores". Although workplace automation has abolished a lot of simple work, there are still areas where well-defined, routine processes are commonplace. The most important characteristic to success in this domain is diligence - getting stuff done properly.

Complicated work rely on getting multiple pieces of work executed correctly and in proper sequence. This requires good coordination - putting multiple pieces of the puzzle together in the most effective way.

Complex work means that there is no one known best way of doing things, and there is no one specific goal to attain, either. Even though most of today's knowledge work occurs in this domain, people easily get irritated when they "just don't know" and still need to product results. The essential trait here is creativity - coming up with a solution in the face of the unknown.

Chaotic work occurs when there is no clear-cut way of doing things. Many people feel challenged working under such conditions, as the constant barrage of new information often invalidates former achievements. Resilience and a high amount of flexibility helps - changing direction whenever it makes sense!

The problem with "Projects"

The complex and chaotic domain are the places where projects crumble: The base assumptions of the project fall apart as soon as people start doing work. The coordinative ability of the Project Manager are of little help when the tasks to coordinate aren't helping achieve meaningful goals. Likewise, the most diligent worker isn't helping the company when the work isn't even going in the right direction.

It's extremely difficult to run a development project with the premise that project management is merely the meta-task of coordinating development tasks, as nothing would need to be developed if everything was clear to begin with.

A lack of flexibility often causes projects to fail in a sense that the outcome isn't needed when the project is done.
Likewise, a lack of creativity often causes projects to turn Red - objectives can't be met by following the plan. In unfortunate cases, the only creativity on a project team might be the project manager's ability to find excuses for the poor outcome.

Unless projects have people who exhibit the flexibility to deal with new information - and the creativity to do without proper processes or still do something useful when goals become invalid - the project is in trouble.

The problem with "Agile"

"Agile" dogma often seems to presume that all work requires flexbility, and that all workers are flexible.
Both premises are invalid. Not only are flexible, creative workers a rarity rather than a commodity - working in this domain should be an exception rather than the norm.
Creativity is often needed to pull unknown stuff into an area where slices of known work can be coordinated and executed, but that work still needs to get done.
Highly flexible people often enjoy the streaks of chaos that allows them to innovate - and they may not enjoy the grind and routine of doing the base work.

In a healthy team, there has to be a place for people who are diligent, for those who are good at coordinating stuff, for those who are creative - and for those who enjoy the whimsiness of the Unknown. Put together, such a team can be extremely effective.

Summary

We need to respect that not everyone is creative and that some prefer routine - and we need to respect those who can't bear routine work and their drive for change. And we are well advised to neither compare nor mix up such work: it's just too different.


Try discovering where people see their favorite work and help them find their place accordingly.

Avoid creating a culture where people enjoying only one type of work feel left behind. It might create a dangerous monoculture!

Order vs. Chaos - a look at the science

Order creates a feeling of safety. Chaos, on the other hand, is a term with negative connotation.
But is order really what we want?

Using an analogy from material sciences, let's take a different look at the struggle of "order versus chaos".


Take a look at this model:

Order is the "frozen state" and Chaos is the "volatile state". I use this example on purpose: Kurt Lewin has proposed a 3-state change model, "Unfreeze-Change-Refreeze". It perfectly correlates to material sciences.

Lewin assumes that organizational structures and/or processes are best kept in a "frozen state". And in many organizations, that's true. Does it need to be true? Let's take a step by step look by examining the states first.

Different states

Frozen = Ordered

A frozen organization is ordered. It doesn't matter how effective or efficient the organization is - things are clear. Well, maybe not so much, but still. There are known structures to uphold, there are known people to address, there's a known protocol to follow and know processes to apply.
This makes things simple: If A, then B.
I go to work in the morning, know what I will be doing - and even when I take a week off, when I come back, I know the exact state where I will resume.

Terms used to describe a frozen state include: "predictable, reliable, convenient". All of these words are positively connotated both with workers and managers.

Hence, the desire to freeze the organizational system.

Along comes a troublemaker. A person who does things different. Who won't accept "That's how we always done it" for a reason. Who breaks rules to get stuff done. Who bypasses hierarchies getting in the way of success. Who messes with people following dysfunctional processes without further ado. Like - me.

In a frozen state, the organization will consider such a person a dangerous foreign body needing to be dealt with. A single person faced with frozen organizations will be forced into one of two choices: adapt - or get out. That's why change initiatives are well-nigh impossible without a strong guiding coalition as proposed by Kotter: It's not about doing things differently, it's about accumulating a critical mass of people with sufficient power to unfreeze the system before even bothering to really go on with the change agenda.

Liquid = Nonlinear

Getting out of a solid, frozen state in physics requires dissolving the bonds between system components. Depending on what you want to change, you may need to un-link structure, people and processes alike - simultaneously!

Dissolving links means that communication structures will no longer work as before, processes will no longer produce the same outcome - and results on any level may change. The bigger the incision, the more likely unpredicted side effects will occur.

People lose the feeling associated with an order state - predictablity wanes, reliability is reduced and people start experiencing the discomfort of needing to think and connecting dots differently. When essential, strong links haven't been dissolved, the system returns back to the former stable state as soon as possible and may even obtain resistance strategies - inoculation to ward off future change.

Going back to our physics analogy, we need to invest energy into an ordered system to unfreeze it. The amount of energy needed to make a permanent change in an ordered structure directly correlates with the strength of the links which need to be broken.

Let's take the example of water:
It takes a rather limited amount of energy to melt an ice cube.
With significantly more energy, we could split the molecular bonds and turn the ice cube into H2 and O2.
Should we desire to reform the very atomic bonds and turn the hydrogen atoms into helium, we need to invest a lot more energy into a much riskier and complicated process.

In either case, the former state will cease to exist - and that's where reactions such as fear, grief (Kübler-Ross) and entitlement come in.

Volatile = Chaotic

Volatile systems do not display the characteristics of an ordered system. The high energy inherent to each particle allows them to move rapidly - making it extremely difficult to predict the next state of even a single component in the system, much less enabling methodic control on the overall system.
In a chaotic state, change doesn't require an investment - it happens continuously and without trigger. Change isn't something that needs to be initiated, much rather, it would need to be channeled to produce something desirable.

In a volatile state, the system's drive to change is bigger than any component's capability to stabilize, hence no change is permanent.

A molecule in a gaseous state would not consider this state "anomalous" - much rather, it would need to be deprived of its energy before entering any other state.

And this is an important part of volatile systems - the components have high amounts of energy!

Like order is produced by draining energy from components, chaos is produced by energizing components.

State transitions

Material state transitions can be measured and predicted with high accuracy - something not quite as simple when dealing with an organizational system combined of a complex structure including many individual people, highly interrelated processes and potentially an innumerable amount of technological dependencies.

State transitions in a frozen organization are often considered undesirable, as people are afraid that something will get broken for good:

As the  "frozen" state of an organization becomes stronger, the more energy will be required to reach the "un-freeze" state which makes state transition possible. Combined with the complexity of the system, the amount of energy required for a successful defreeze might be roughly the same amount required to enter a volatile state - and depending on the size of the desired change, an excursion into a chaotic state may be required.

When being unfamiliar with the chaotic domain, there is both the danger that chaos gets out of hand or that when the system gets into a stable state again, that state is undesirable.

The false Order-Chaos dichotomy

Frozen systems are stable, but they aren't very malleable. The key characteristic of frozen systems is their lack of energy. An organization with stable structures that lack energy is in constant danger of being stuck in the wrong place - and won't be able to make the necessary move to remain sustainable.

On the other end of the spectrum, chaotic systems aren't stable - and equally un-malleable, albeit for a different reason. The key characteristic of volatile system is their high energy - and therefore, the impossibility to ever nail down anything.

It's not so easy to say whether order or chaos is better - that would depend on what you want to achieve. Based on the points above, we should realize that we're not forced to choose between order and chaos. The choice is a false dichotomy.
Just because water isn't ice, it doesn't mean that you'll die from steam burns.
It could equally be a refreshing glass of cool water or a warm cup ready to make some tea.

The idea "If it's not ordered, then it's chaos" is nothing more than a false dichotomy: There's a large spectrum of conditions between frozen and volatile - and while neither of the two extremes is specifically habitable, the range inbetween very well is.

Get used to change

When you look at a glass of water, you can't tell where every single molecule is. Even if you knew where it was five seconds ago, you can hardly tell where it will be in a few seconds. At the same time, you can tell a few things with fairly high confidence:

• You're looking at a glass of water
• The molecule in question is within that glass of water
• That molecule will still be within that glass of water in a few seconds.

You can even make more reliable predictions:

• If you throw a pebble into the glass, the water will (for the most) remain where it was.
• The pebble will not significantly affect the way your water behaves.
• When you take the pebble out, the water will look like it did before.

Interpreting the analogy, the liquid, non-linear state is both more flexible than the ordered and more reliable than the chaotic state. 

If you want to keep your organization robust to outside interference, you need to abolish the idea that everything needs to be in place: The ordered state can't deal with changing circumstances. 

In an ordered state, Lewin's "unfreeze-change-refreeze" process is essential to adapt.
In a non-linear state, there is nothing to unfreeze, and nothing in need of being re-frozen.

The practical interpretation

We talk a lot about "Agile Transformation", and in the minds of people this is unfreezing a non-agile organization, changing it towards an agile organization, then refreezing it in its agile state.
There is no such thing.

The agile organization is like water, constantly in a nonlinear state. Change in an agile organization isn't a project. Instead, everyone and everything within an agile organization is constantly subject to change.

Every person thinks about new, better ways to achieve things every day - every process can be scrutinized and modified at any time. When outward circumstances change, the agile organization doesn't start a massive adaption initiative, they just do what it takes to deal with the new circumstance.

And that's why you can't "buy agile" - to be agile, you must be in that liquid, transient state - at all times!

"Googlewins Law" - The Google Argument

Maybe you've had an occasion with "The Google Argument" before. I call it "Googlewin's Law". What is it and how does it damage dialogue?

In homage to Godwin's Law, I call for "Googlewin's Law", and would phrase it like this:

"As a technical discussion grows longer, the probability of a comparison involving Google approaches 1"

I have observed an emerging trend that when meaningful arguments run low, someone "pulls a Google" (alternatively Linkedin, Amazon, Facebook) in an attempt to score an intended winning strike. However, most often, the invocation of Google is nothing more than a fallacy.
Here are the three most common uses of the Google Argument:

The positive Google Argument

When developers want to do something which could be called "nerdfest" and run out of meaningful arguments why doing this is a good idea, they invoke the positive Google argument:

"We could become the next Google with this". 

Typical invocations could be: "With this ranking algorithm, we could become the next Google!" - "With this sales platform, we could become the next Amazon!"

Here is why it's a fallacy:

Google never tried to become great, they tried to do something that happened to work, and because they did that exceedingly well, in all domains - from technical implementation over marketing and sales all the way to customer service - they succeeded. Oh, and they happened to have great seed funding.
Google did not become great because of one good technology, they became great because they happened to do a whole lot of other things right as well in a market where one stupid move can cost you everything.

So the next time someone pulls a positive Google on you, just ask: "What makes you so sure we don't become the next Blockbusters with that idea?"

The negative Google argument

The opposite of the positive Google argument, used as a killer argument against any form of innovation or change is the negative Google argument:

"We don't need this. We are not Google".

Typical invocations sound like: "Continuous Integration? We're not Google!" - "Microservices? We're not Google!" - "Virtual Machines? We're not Google!"

Here is why it's a fallacy:

Not everything Google does is only helpful for Google. Google is using a lot of techniques and technologies that help them achieve their mission and goals easier and more effectively.
Google has even created quite a number of useful tools, frameworks and techniques that are available open source (such as Angular) simply because they are useful.
If everything that made Google successful was anathema, you shouldn't even be using computers!

The appeal to Google

When lacking evidence or sound arguments, what's more convenient than invoking the name of a billion-dollar-company to make your case? Who could argue against an appeal to Google:

"Google also does this." - "Google invented this!"

Typical invocations would be: "Of course we need a distributed server farm. Just look at Google, they also do that!" - "Our product search page needs semantic interpretations. Google also does this!"

Here is why it's a fallacy:

First and foremost, unless you're in the business of selling advertisement space on one of the world's most frequented websites, chances are you're not going to make profit the way Google does.
Second, Google can afford a technology infrastructure that costs billions, because that's what generates revenue as well. There's an old latin proverb, "quod licet iove, non licet bove" (lit. "What is suitable for a God is not befitting an ox")
Third, Google has many billions of dollars to invest. It doesn't hurt Google to make sink $100m into a promising, yet ultimately unsuccessful innovation. I mean, yes it hurts, but it's not lethal. Can your business afford sinking $100m for zero returns? If so, you can appeal to Google, otherwise I'd be cautious.

Summary

The next time someone invokes Google, Facebook, Amazon, LinkedIn or even companies like Zappos, Spotify or whatever - think of Googlewin's Law.

What worked for others has no guarantee of working for you - and even though you are not them, not everything they do is bad (such as, for example, breathing!).

Google is not a reason either way.

Feel free to ask, "Can you rephrase that statement with a comprehensible reason that has a connection to our business?"

The system: People

To successfully change the culture within an organization, we need to understand the system we are operating in and how people within that system interact. This isn't as simple as it looks, so here is a standard map ...

People and Interactions over Processes and Tools ...

The above is a proximity model, where people who are more likely to interact are drawn in close vicinity. YMMV.

Your team

The first circle is your team. In case of Scrum, that would be the developers, the Product Owner and the Scrum Master.
Who interacts with whom, and how should these interactions look like? The Scrum Guide has a few things to say on mandatory Scrum interactions - for example, Planning, Refinement, Review or Retrospectives. Those are the objective, process-driven interactions.
What the Scrum Guide can't help you with: Who likes whom, who can work well together - and: which factors bring people closer together or further apart?
Detractors could be obvious stuff like different work ethics, fandom (Star Wars vs. Trekkies, for example), skill animosities (e.g, tester vs. coder) but also hidden things like subtle bigotry, not liking another person's choice of diet (e.g., garlic/onions) etc.
All of these will affect how well your team can interact. The good news? All of this is within your team's sphere of control - as long as you can talk about it, you can find a way to knit together.

Your organization

The second circle is your organization. Most traditional enterprises have roles such as team leads, middle managers, senior managers, finance, HR, marketing, sales, customer service etc.
All of these people will affect your team one way or another and the potential interaction points are already too many to count.
While the Scrum Guide states that the Scrum Master should protect the team from outside interference, it's hardly practical to create a complete bubble of isolation around the team. Especially in the early phases of an agile transition, the direct and indirect effects of managerial roles may still be very strong, oftentimes in detrimental ways. The solution can't be digging trenches - you'll need to provide education on the effects of any influence taken upon your team.
As management finds their new role within the changing organization, the interactions with classic business departments also change: the team gets closer to functions like sales, CSR or marketing - and these people, too, will need to learn which functions are better maintained within your team and which information needs to be communicated straight between the team and them.

I have heard many Scrum masters talk about "drawing boundaries" - while I personally would favour "blurring boundaries", i.e. integrating the different business people in ways that remove indirection and delay, right to the point where information is freely available and collaboration happens without structural limitation.

Immediate surrounding

Your company doesn't operate in a vacuum. There are many second-order interactions going on, the most important being between the customer and your organization. Depending on whether your team is working as business support or in marketable product development, it's a great idea to move the team as close as possible to (in the best case: directly into contact with) the customer.

In traditional organizations, you will see that sales people and marketing try to bond with the customer - which can be both a blessing and a curse for your team. These people, too, need to learn which second-degree interactions are helpful and which aren't. For example, making promises to the customer without consulting the team is oftentimes a recipe for disaster.

Then, there are suppliers and competitors. Suppliers may or may not have the flexibility to support your team's newfound ways of working, which can become a massive problem unless addressed. In many cases, vendors find themselves in an uncomfortable situation when their client(you) is asking for more flexibility, in terms of both contracts and speed.
Your competitors will strive to be more agile than you, so keep an eye on what they are doing at all times. As long as you can learn something from them, you have homework to do. In complex environments, your suppliers will also be working closely with your competitors - which can create extremely interesting dynamics that can become very dangerous for your organization unless properly managed.

And then there's all of those other second-degree interactions: Friends and family, (social) media. You can't possibly hope to change these people and we're quickly talking about thousands of possible interaction points for a single team, yet these do affect your team as well.

Never forget that these interactions are highly intertwined with all the other interactions previously mentioned: a single press release by Markting can cause hell to break loose within your team, while a careless blog post created by your developers could void a year's work of sales currying favour with a potential client.

At least the good news is that up to this point, the interactions are either directly under your team's sphere of control - or at least, they can be influenced one way or another. That means you need to be finding ways to make those interactions favorable for your team.

The world

Life would be simple if everything could be brought under control - but it's just not that simple: Imagine that you did everything right, and along comes a new law that makes your product illegal: What would you do? It's not as easy as having a chat with lawmakers and undoing the law.
There are so many forces far beyond your control which can devastate everything your team is doing. Thought leaders coming up with new ideas which might imply that you've been working in the wrong way, industry leaders disrupting your market segment, political leaders interfering with your entire industry - and you might have no way to deal with it other than to cope with it!

The impact of "world level" interactions can also be both harmful and helpful - for example, a new invention may boost your team (if management lets you take advantage of it) or favorable changes in the market may boost your sales, thereby your financial resources. There are also cases where new laws or political changes might work in your favour and drive customers straight to your company.
These same effects could be positive or negative - in some cases, both. For example, that new helpful invention might boost your team - but also force you to invest heavily into it, draining resources elsewhere. Or that new political situation might drive flocks of customers right to your company - while the necessary customization changes overburden your team!

The world is beyond influence and control. In the Cynefin Framework, it would correlate with the "Chaotic Domain". You can't shield your team from the world's influence on your organization (and therefore, your team). Unless you're in a highly lobbying segment with massive public influence,  you can't tell the people of the world how they should behave, and you can't educate the world, either.

When it comes to interactions between the world and your organization, your only strategy is - adapt. That's what "being agile" is all about.

Summary

None of these interactions can be completely neglected - yet which of these interactions are crucial for whom, and when, constantly changes, so you're shooting at moving targets.

I hope you liked this small introduction into "People of the System" and what their interactions mean for your team. If you are an agile coach, understand that you can't always work on all of these, so you will need to observe the most important interaction points and work directly to make them favorable for your team.

"Being agile" means making the interactions within your sphere of influence more favorable - and learning to get along better with the interactions that influence you.