"Choosing" not to be offended

I ran across another example along the theme of "Why don't you just choose not to be offended by that word"

Short answer: Because of how the hippocampus and limbic system work.

Kind of longer answer: Because the meaning of words is tied to contextual memory, identity, stories, and emotions. We can't choose which emotions to shut off without shutting all emotion off (See Brene Brown's work), And threats to Status, Certainty, Autonomy, Relatedness, or Fairness (several of which will most likely be present if you are offended) are interpreted by the brain in the same way as a physical threat (See David Rock's work).

I had intended to give a MUCH longer answer unpacking all of the above. But, the summary is this - Asking someone "Why don't you just choose not to be offended" is in essence asking them either A) Override millions of years of evolutionary biology or B) Change their identity in a fundamental way by either ignoring the context in which they interpret the world, the groups they self identify with, the status with which they hold themselves, or the protections they feel for others.

So no, it's not that easy to "just choose not to be offended."

Chasing the exit

I've only lived in San Francisco for two years, but I'm catching on that the mindset here is "chase the exit" not "delight the customer" (failing to realize how much more likely the latter makes the former). With that mindset the state of code quality is not surprising.

There are some seemingly practical outcomes from this. One of which is a bias toward fast features, leveraging frameworks, and little time spent "doing the dishes." Because, honestly, if 7/8 of your startups are going to fail, you only have to spend the time/money to clean up 1/8.

A problem with this "practical" mindset is that the skills required to remove complexity from a system are significantly more refined and harder to come by than the skills needed to keep a system simple in the first place.

I may expand on this later, but I'm interested in others thoughts and observations.

On Leading Change

We talk a lot about leading change in the agile community. Some of us are even in positions where change is a major portion of our job description whether we are change agents, change artists, or just plain old coaches. We want to change practices, behaviors, mindsets, and often entire cultures. Unfortunately, I rarely hear about change in the context of changing ourselves.

"It's not my job to make them better.  It's my job to make me better."

One of the most profound things that's been said to me about leadership and change is the following koan: "It's not my job to make them better. It's my job to make me better." This short phrase holds so much wisdom. I've been unpacking it for years, yet I'm sure it will continue to provide insights for years to come.

If I can continually work to be a better engineer, a better manager, a better learner, a better person, if I strive for probity, then change will happen within me and around me. Because change leadership is not about making followers. It's not about instilling or inculcating or impressing upon others. Real change leadership is about being worthy of emulation.

Fundamental Principles of Agility

I think a lot about fundamental principles. I've found that a solid understanding of principles allows me to derive understanding of more complicated things.  Within the Agile community I hear a lot of talk about culture, methods, frameworks, and spirited discussions around #hashtags. But, rarely a straight forward discussion of fundamental principles.

To begin, when I speak of principles here I am not talking about the principles behind the Agile Manifesto. These are statements of values which help you know right and wrong and that influence your actions (e.g. a person of principle).  Instead, I am using the term to mean a law or fact of nature that explains how something works or why something happens (e.g. a principle of chemistry).

In the article "Agile and Waterfall: More Different Than You Think" Tim Ottinger lays out an argument for why mixing and repurposing practices between waterfall and agile development leads to unsatisfactory results.  In the process I believe he uncovered several fundamental principles of agile in the form of certain axioms. I've since refined these axioms into the following set (given with a comparison to a more traditional view).

Mindset Axioms

Agile	Traditional
We may be wrong in our assumptions, and even if we are currently right the world may change, therefore...	We are right in our assumptions, and the world is fundamentally static and unchanging, therefore...
Changes are inevitable and needed for success	Changes are an indication of error
More planning will give us a false sense of certainty and likely lead to errors in decision making	More planning will allow us to reduce uncertainty and correct errors in decision making
Inspection is to learn about the current state of the world and correct the plan	Inspection is to find deviance from the plan and control changes
Feedback is the primary signal for adjustment	Milestones are the primary signal for adjustment

The first is the fundamental agile principal. We assume the future is unknowable and therefore our assumptions are possibly wrong. From this we can derive the rest; the limited usefulness of planning, the need to continuously inspect and adapt to understand the current state of the world, the value of feedback.

As an example we can use these fundamental principals to derive the purpose of different Scrum ceremonies.

• Sprint planning provides an opportunity every iteration to adjust to a new state of the world.
• Stand-up/Scrum provides a daily inspect and adapt cycle where team members sync up and and can adjust to changes based on what they've learned in the last 24 hours and broadcast that new understanding to others.
• Sprint reviews allow an inspect and adapt step of the product every iteration. Stakeholders are able to experience working software in their hands which often leads to new lines of opportunity (see exaptation).
• Retrospectives allow an inspect and adapt step of the teams process. They are able to adjust how they work based on knowledge of the world as it is today. 

We also see the centrality of the inspect and adapt cycle in agile technical practices

• Continuous Deployment allows a faster feedback loop between customers and the team
• Continuous Integration allows a faster feedback loop between parts of the system
• Local automated tests allow a fast feedback loop before code is pushed to others
• Writing a failing test then making it pass the simplest way possible allows a fast feedback loop showing that your codes does what you expect and allows the design to be adjusted based on what's learned as you work
• Pair/mob programming provides a faster feedback loop from peers to help improve design, hold context, and correct errors

All of these practices are useful if we understand that we can't "do it right the first time" because the world changes. Better designs will emerge, new technologies will be created, we will find new opportunities to explore. We as individuals are constantly changing as we learn and find new and better ways to solve the problem at hand. We co-evolve with the projects and products we create.

There are other fundamental principles behind individual practices related to flow such as work-in-process limits and small batch sizes (principles of queuing theory) covered very well by Ken Rubin in Essential Scrum and  Donald Reinertsen in Principles of Product Development Flow. However, I think you'll find that they are more easily understood when approached from the perspective presented here.

A transition to Baseball.

Having seen a few slow and stalled business transitions in my day I thought I might describe some patterns in the absurd.  Imagine if you will a business that several years ago decided to transition to becoming a professional baseball team.

If they follow the transition patterns of many companies who attempt to make fundamental changes to how they work this is what it might look like today:

Knowing the rules
The company still doesn't know the rules of baseball.  While that might surprise you it shouldn't. After all, children play the game and we've all heard about baseball so there was no need.  Besides, a few people read them several years ago and said they were simple.  Maybe they didn’t study them well enough to understand the purpose and underlying principles.  However, that doesn't matter because the company operates in the real world, not some theoretical rule book land. They wrote their own rules based on how things were already done and what they could glean from observing other baseball teams.

Practice and learning
Because baseball is big business they decided that batting practice isn’t important. It was noted to all that the company just can't afford practice at this time.  Sure, people pointed out that the largest and most successful baseball teams practice even more than they play. But those teams have the money to do so.  Once the company is successful they agree to set some time apart for practice. But for today, instead of practicing they just schedule more games.

Focusing on fundamentals
Everyone at the company is fixated on hitting home runs. However, no one is looking at improving the basics that make home runs more likely; stance, grip, breathing, focus, power generation, swing, accuracy.  It's clear that they have a complex home run problem and those things are simple basics that everyone should know anyway.

Gathering data
No one actually gathers data on games won/lost, batting averages, etc., instead they trust their gut. Alternatively, some try to derive such things from ticket sales which are much easier to track and measure on a simple dashboard.

Providing value
Finally, the 25 people on a “team” are each continuously worried that they don’t have the ball.  To deal with this they all run to wherever the ball might be.  While this is exhausting, and they have a tendency to get in each others way, at least they don't look idle.

Expected outcomes
Having spent much money, time, and effort the projected deadline for completion of the transition is here.  Publicly there is pressure to say it's been a huge success. People are often heard saying that baseball is "in the companies DNA."

Looking back people now question why they tried to transition the business to baseball. Sure, there are stories of several other major businesses having success as baseball teams. There are plenty of books, magazine articles, and even stories of parents who played baseball with their children. However, having gone through the process and seeing how little positive benefit the company received from this transition they have come to the conclusion that baseball is a sham.

Clearly, no one could ever build a viable business this way.

A first step

It always seems hardest for me to take the first step.  Such is the case with this blog. It's been sitting empty for nearly two years as I waffled about any number of subjects.  I've spent hours over those years typing, but somehow never publishing a single post.  Today, I'm taking the that first step.

This will be a place for me to share and explore ideas.  Mainly about agile, business, software, and communication research as these are topics I think about regularly.  It will also be a place for me learn and expand my skills in writing and conveying ideas to others.

I'd like to thank Tim Ottinger for helping me take this first step.  He suggested a simple formula for getting started: 3-2-1.  Write a three paragraph post.  Followed by a two paragraph post.  Then a one paragraph post.  With that simple direction in mind it seems I'm nearly ready to take the first step.  

Time to hit publish.