Friday, October 2, 2015

Principles for Large Organizations

I was speaking with my friend Bryan who, like myself, does a lot of work with very large organizations. Many of them are great places and have sincere interest in being wonderful places to work with wonderful people. Sometimes, though, they struggle.

In considering the nature of their struggles, I realized that I've collected or formed some observations of dynamics and I've not really vetted them all publically. I'd like to take this moment to think out loud and, with kindness and curiosity and empathy, see if we can develop and refine these observations -- or possibly strike them entirely if they seem utterly false.

Please join me via comments or emails ( or to let me know what you think about these observations, what I'm missing, and what I can do to fill out the set better. Just remember, this is about curiosity and systems -- I'm not here to tear anyone down.

Dunbar's Number

Researcher Dunbar noticed that primate "tribes" have an approximately maximum size after which they can no longer maintain vital relationships. When primates exceed this number, the tribe splits. It doesn't matter what events trigger the split, it's more or less inevitable that the split will happen.

Smaller primates tended to have smaller tribes, whereas others seemed to tolerate a larger tribe size.

Dunbar discovered a correlation between the surface area of an animal's brain and the tribal size of the species. This correlation seems pretty strong, and has good predictive power when applied to other species of primates.

By extension, Dunbar reasons that a human  "tribe" can only have about 150 members or so before the tribe splits.

A corporation is often far beyond the "Dunbar number." Each individual in the organization has "slots" consumed by family, hobbies, and other connections. Most of us can't really work in teams of 40 or 50 comfortably, let alone 200, 500, or 8000.

It may be an essential understanding that corporate life is ruled by Dunbar's number; with the constant issue of working with people who are not "in our tribe" -- with too many people and too infrequent an association to create and establish trusting, close, nurturing bonds.

Corporate life takes place at a distance for most people, once you get past their local group. Note that a "team" on an org chart may contain members of entirely different tribes, and their split-membership may put them at odds with each other or at least make it hard for them to establish and maintain any meaningful relationships.

The Law of the Second Floor

The law of the second floor builds on Dunbar's Number by stating that "nobody two levels above OR below you on an org chart really understands what you do for a living."

The programmers and testers building a product don't really understand the life their grand-boss is living. The distance is too far, which puts the grandboss into a different tribe which deals with different problems.

Likewise, up in the executive suite it is quite hard to remember that the front-line employees are meaningful human lives worthy of individual care and dignity and respect. They all start looking like fixed expenses, sales numbers, say/do ratios, or other similar aggregations of numbers. This isn't by choice, but is a problem of scale and social distance. After all, these are not the people we interact with; they are the people who interact with people who interact with the people we interact with (you may have to read that last sentence three times).

By the law of the second floor, dehumanization of remote bosses and employees tends to be the norm. Attempts by individuals to pierce the levels and establish human contact tend to be treated with suspicion and distrust.

The Presence of the Secondary Topic

Individuals working in a company are people who chose to come to work there. They tried hard. They went outside of their comfort zone to produce resumes or make contacts and have passed through layers of job interviews to try to acquire a position.

That position is important. Eventually the work done by individuals in a corporation becomes a secondary concern. The primary concern is to maintain or improve one's position in the organization.

While it's not politically appropriate to speak in those terms while inside the organization, this concern is the secondary topic in most conversations that take place across hierarchy levels.

The Presence Of Secondary Topic means: "Every discussion you have with your boss is really a discussion about your position."

The subtext of the conversation is overloaded with questions: Do I seem like deserve to be here? Is it clear I am doing my part? Should I get promoted? Is this a reason I might be dismissed? Do I look redundant? Am I crucial? Do I get to stay here?

Because the boss is "of a different tribe" and has a strong influence on how or whether we will be perceived in our organization, and because the organization has direct influence on our pay and social position, conversations always have a subtext.

A software team can miss a release date, can release bugs, and still retain their places. However, one hears stories of people being released for careless "career-limiting moves" (CLMs, they are often called in the boardrooms).  Projects and positions can evaporate for political reasons. This creates a sense of fear and vulnerability in people when they are speaking to the people above them in the official hierarchy.

This is frustrating to all managers and to all employees, and seriously gets in the way of discussions about the work, tactics, strategy and performance of the company.

Singh's Inevitable Avoidance

Asshok Singh suggests that when organizations don't know how to solve their problems, they will tweak their process to accommodate their dysfunctions.

A company can't afford to quit operating, nor can it afford to operate unprofitably. Therefore, it will maintain operation it the best way it knows, even when that way is painful or unpleasant or even self-defeating. We can't ask people to behave better than they know how to behave, or produce more than they know how to produce.

So when there is a problem, we route around it. It's a wonderful testament to human ingenuity and flexibility. But it's also another way to stockpile pain until it all blows up down the line.

Why do organizations tend to have quasi-agile-like processes? Because they have to route around all the dysfunction that is associated with working beyond Dunbar's number, across the 2nd-floor law, and in light of the secondary topic.

This process work isn't easy. It's not like people are only working with their 12 best golfing/drinking/running buddies. In a large company, there will be issues that seem to be (and probably are) too large to address at the moment, and so they are avoided for a time.

The important thing to remember is that "a problem deferred is not a problem avoided."

Distilled Culture

A company's processes are a distillation of the company's culture into a set of rules.

These rules may directly contradict the company's stated values, in which case the stated values are ideas that some leaders have hopes to aspire to (an "end state") and the actual policies are an indicator of the culture to date (the "beginning state" or "late status quo").

Sometimes, the stated values are a smokescreen, though, and attempts by people within the organization to move policy decisions into alignment with the stated values can be met with disciplinary measures or dismissal (see Secondary Topic).

There are people in the organization who want to move the company in the direction of values, and who have the authority to approve or support such attempts, but they may often be divided by more than two hierarchical levels, or worse have no knowledge of the people who need the support and encouragement.

The Trust Transaction

The trust transaction is the transaction of completing assignments well and in return having more autonomy and opportunity. 

When trust is low, governance is necessarily high. 

When trust (delivery) is particularly high, governance is unnecessary.

Many organizations have very little trust or delivery until a facilitator with authority helps them to begin negotiating this transaction. Often teams need "enough trust to grow into" and this comes by trimming down the amount of per-person governance and bookkeeping. In return, if they deliver more often and with a higher level of transparency, it is easy to afford them a little more trust.

In time, if there is enough progress or success, the managers are happy to treat a team as an atomic, autonomous unit. If, however, teams or individuals "go dark" (work is invisible) then governance is increased and management tends to micromanagement.

This is only natural in light of the other principles in this blog.

Power of Agreements

Finally, after all of these things are considered, the most important breakthroughs may come by realizing that policies and structures and all the elements of culture are not natural laws or government-mandates.

Ultimately, how organizations work is really just a bunch of agreements made by people.

It's all made up. None of it is real. Some of it is quite useful.

If a company is made of agreements, then it's up to the people working in it to ensure that their agreements were consciously-made and remain beneficial.

Many people would be happy to endure the tirades and public shaming of a dictatorial boss who would also make them rich and famous. It's a transaction. Others are happier working in more egalitarian environments and wouldn't stand for it.

Some people work in organizations where self-actualization is a primary cultural more, others where people are resources to consume. Some people value working on powerful teams,  but others where they're left alone to do their work as they choose without interactions. It's all a set of choices.

But it's all made up.

Possibility thinking begins with the understanding that an organization is pretty much what its people choose to make it. It grows and develops according to what its people are willing to trade, and what they're willing to trade for it. 

How Is The "Year of Living Shamelessly" Going?

Somewhere back in the first quarter of 2015 I decided to declare this my Year of  Living Shamelessly.

I decided this means that I will live by all the best guidance I've been given, to the best of my ability.

I won't surrender my responsibility for my actions and consequences to "but I was following the recipe" but instead, I will try to practice (in a mindful way) those teachings which I find to be most profound.

These teachings come from my protestant upbringing and scriptures, from my early and current mentors, from people I respect and love, from many books on processes and human behavior, from psychological and neuroleadership sources, basically from anyone I've listened to whose teachings have resonated with me in a deep way.

I've been pushing forward on these fronts:

  1. Empathy
    One of my key learnings from last year was that considering how you would feel in the other person's shoes is not empathy; it's self-involvement. It led me to judge others by how well they performed as Tim Ottingers. It was unfair.
    Now that I understand it's not about how I feel, but how they are feeling.
    This has begun a transformation in how I meet people, how I enter groups, how I listen, and who I can assist or support. It's become very important to me to seek the kind of connectedness that only comes from seeing others as whole separate beings from myself.
  2. Replacing Judgment with Curiosity
    This learning is a very old one, going back to at least "Judge not, lest you be judged." But it goes deeper for me than it did. It's not just about criticizing others, but about replacing the urge to declare their actions and opinions as "right" or "wrong" with curiosity about what it is like to be them in the situation. Why does their action seem to be right in their situation? How does it feel to them to be facing these dynamics? What is the system like in their lives? In their heads? What do they fear? What do they want?
    This is going against some very old habits of sarcasm and recreational anger, but I'm finding that it has the power to open me up to people in new ways, and it feels like a soul-cleansing.
  3. Looking for ways to say yes
    I'm afraid of "yes." If I say yes, and then for some reason I can't do or say or be the thing I say "yes" to, then I feel it as failure and shame.
    Often when I'm asked to do something, it takes me to preemptive shame. I feel ashamed as soon as I'm asked so I bring out a convenient "no."
    This is silly. In many ways, it's like not trying new foods or not meeting new people. It comes from anxiety and not from love or adventure. It's weak. It's one of the more shame-inducing dynamics.
    Now I know that if I'm interested, if it is good and right, then I need to negotiate to a "yes" that I do feel good about instead of rejecting an experience. I can also say "no" without feeling shame, if I've tried in good conscience to make a win-win negotiated "yes."
    This is big stuff.
  4. Developing Confrontational Skill
    I used to be confrontational in a bad way. Then I learned to avoid confrontation. Then I learned that avoiding confrontation is really just stockpiling pain for later and that eventually things boil over in very bad ways.
    So I'm learning to be confrontational in a shameless and empathic and systems-curious kind of way. This is a hard push for me, but on my good days I'm getting traction. I think this may be the biggest challenge for the year.
  5. Rejecting Recreational Anger
    Recreational anger is the term I use for things ranging from "The Springer Show" to Chicago politics to certain episodes of South Park and especially to the style of "comedy" that many performers are turning to these days. Basically, it is being angry and judgmental of others in order to feel good about yourself and your peers.
    Anger has a place. It is an energy to stand against oppression or abuse of others. It's possibly useful. But the adrenaline and excitement of being angry, and the ever-present sense of self-righteousness makes it addictive.  It can draw people to an urgent cause ("you should be furious about X" is a clickbait headline).
    But is it healthy? Does it make those relationships with others more vital and empathic? Does it make us stronger and more kind and more helpful? "All things are allowable, but not things are beneficial."
    I avoid shows that encourage me to dislike others. I avoid "comedy" that rants against one political party or another, or atheists or religions, or women or men. The anger and condescension are certainly exciting and enjoyable. I am simply choosing other ways to entertain myself these days.
    I have decided to go cold-turkey against wallowing in judgment and reveling in shared anger. It is surprisingly easy most of the time, and wholly pleasant. Why seek negativity when the world has much better to offer us?
    However I still indulge in the occasional John Oliver rant on YouTube even though I recognize that his humor is largely recreational anger. He's just so darned witty. I'll keep working on that. Can I give it up? 
Am I perfect? Have I attained mastery in these five areas? No. Not yet. Not by a long shot. But I find that it's helping me become someone I'm accepting and proud of, which I think is pretty important. Better, it's helping me become someone that others are accepting and proud of, and that's deeply important to me.

Abe Lincoln once said:
Every man is said to have his peculiar ambition. Whether it be true or not, I can say for one that I have no other so great as that of being truly esteemed of my fellow men, by rendering myself worthy of their esteem. How far I shall succeed in gratifying this ambition, is yet to be developed.

My Year Of Living Shamelessly is a developmental experiment.

How is yours going?

Thursday, September 24, 2015

The Manifesto Didn't Start It All

Often it's not the meat of an agile criticism that bothers me, but the revisionism.

I rather like the article by Nick Kolakowski, except for this:

"Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods"

Likewise this by Michael Church:
The “Agile” fad grew up in web consulting, where it had a certain amount of value: 

Not quite.

It got a name and a manifesto then, but it was a gathering of practitioners of "lightweight methods" (and one waterfall guy: Hi Steve) who gathered and wrote the manifest to describe what they had been doing for some time.

All the agile methods of the time had been hammered out in real projects for years.

XP, for example, was begun with the 3C project in 1993 and was being written about extensively in comp.object usenet group well before the web, and before it even had a name.  It was a collection of radical ideas at the time and was hotly contested. That's where I first became aware and peripherally involved in Agile.

Scrum's roots go back to 1986, but it was described in a paper in 1995 by which time it had been in use for a while.

You can learn quite a bit more about the authors, if you want to spent a little more time at the Manifesto site. It is dated (many of the web sites and company affiliations have changed) but you can see where they came from.

So, no, it wasn't invented by methodology salesmen in 2001 at a meeting.  It was not dreamed up out of whole cloth without vetting in real world situations. It wasn't feckless hopeful thinking.

Sometimes critics forget that it began as a real thing, a consolidation of values and principles from real work done by real development teams.

That being said, it's had plenty of time to go wrong.  I'm still hoping we can Take Agile Back.

But I thought I'd help clear up the bad assumption about Agile origins.

Thursday, September 17, 2015

Confirmation Bias and The Twelve-Day Technical Problem

Charlie is a developer. He's just been assigned/volunteered to take on an interesting technical challenge. It will involve research, learning, and experimentation so it is exactly the kind of assignment that most developers would love to have.

If the solution to the problem was clear cut and obvious, then it would already exist in a library or a book or in google or stackoverflow. It doesn't, to the best of Charlie's knowledge. Of course, he looked. This isn't Charlie's first rodeo.

Vinnie is Charlie's manager. He's a smart fellow, and has quite a bit of experience. He has a good sense of organizational dynamics and deadlines and an amazing memory for minutiae that escapes other managers. He can juggle tasks and schedules like a wedding planner, and never misses crucial dependencies. He knows all his employees' spouses and children by name.

Vinnie's sense of deadlines and productivity naturally enough led him to ask Charlie how long this technical task will take. That's a reasonable question. The only problem is that Charlie doesn't really know how much research or experimentation might be necessary. He guesses that 10 days will be enough, and Vinnie marks the date on his calendar.

Monday is retrospective and sprint demo, so Vinnie and Charlie are very much involved in that work. Tuesday is planning meetings and the beginning of the sprint. Charlie nearly signed up for a sprint backlog item, but Vinnie (ever watchful) reminded him that he had a special task already assigned.

Fast-forward 6 days. Vinnie comes to see if the task is half done. Charlie doesn't know. He's tried several things that didn't work, and has dropped two promising-seeming tools that can't really handle this particular challenge. He's got a new design.  Vinnie asks if it's hopeless, and Charlie lets him know that he's vectoring in on an answer and once he knows what to do the implementation will be quick. Vinnie checks his calendar and feels a rising nervousness.

Day 7 comes, and there is no solution. Charlie's abandoned a couple of more designs and has got an example in proof-of-concept form that handles most of the cases they'll encounter in production (according to the data set they've generated) but won't cover several very crucial examples. Charlie says some more digging is necessary.

On day 9 Charlie still doesn't have that last little bit done. Vinnie reminds him of the deadline agreement. The excuses begin to flow. The problem is "hard." The solution is "novel." It is a "research problem" and he shouldn't be held to the deadline because 10 days was just a "guess". Besides, a day and a half of that time was dedicated to sprint activities and Charlie was still responsible to teammates for technical advice on other parts of the system.

Vinnie turns red and leaves the room to ponder. On his way to the coffee machine in the afternoon he sees Charlie playing foosball.  Vinnie realizes that Charlie is just not taking this seriously enough. As a manager, Vinnie understand how to motivate people.

Vinnie sends Charlie back to his desk and vows to keep his eye on the recreational equipment for the next day or two. Charlie was hoping that if he could just take his mind off the problem for a few minutes, he could return with mental clarity. Instead, he just trudges on in a fog.

Day 10 comes.  Charlie is talking on the phone to somebody. Vinnie demands that Charlie put the phone down and get back to work. Seeing Vinnie's mood, Charlie offers no resistance. He shrugs, hangs up, and turns back to his computer. Vinnie walks away satisfied that he's made it clear to Charlie that he's serious about this work. He's "set him straight."

Charlie had been conversing about the work with a colleague who had mental freshness and a different background. Had the conversation continued another 20 minutes, it could have saved Charlie at least a day's work.

Day 11 comes and goes. On day 12 Vinnie is seen yelling at Charlie, not mincing words, using strong language, letting him know how much is on the line and how important the work is, and how Charlie needs to focus and take it seriously.

Charlie is frustrated. He's been working hard the whole time and suffering "abuse" for the last several days. Now he's very nearly done, but he's standing in Vinnie's office listening to a motivational talk about the finishing the work when he could be finishing the work.

It's frustrating, but of course Vinnie is in the position of power and in no mood for counter-argument. Charlie holds his tongue, and agrees to focus and keep working for an answer.

He agrees to send bi-hourly status reports via email. Each takes about 15 minutes to write and edit to make sure that he doesn't accidentally trigger Vinnie's anxiety. Each distracts him from the work he's trying to do and focuses him on the frustration and rising anger he is feeling.

He works late that night to make up for the time he's spent trying to placate Vinnie.

Day 12 and Charlie is fixing the mistakes he made because of working into the night last night. Again a visit and lecture from Vinnie.

This time, Charlie allowed his mind to wander (as tired as he is, focus is difficult) he realized exactly what was needed to get that last little exception handled. He waits 20 minutes for the lecture to end and codes up the rest of the solution. By 4:20 in the evening, it works for all the cases in their data set and he pushes the code to QA.

Duelling Conclusions

Lessons learned here will be generalized and incorporated into the fabric of "what work is like."

To Charlie this is a story of having to endure ridiculous motivational tirades in order to fix a problem that, fairly, would have taken 10 +/- 2 days not matter what. It might have taken fewer days if it wasn't for the manager's interference, but it was still finished more-or-less on time.

Charlie's lesson learned: interacting with managers is distracting, unpleasant, and fraught with political peril. He will avoid Vinnie as much as possible in the future, and placate when avoidance isn't possible.

This is, of course, an awful theory of how people on the same team should work together, but from someone with little organizational power, it is the best he feels he can expect.

To Vinnie it's clear that the work wasn't being done until he started really pushing and leaning on Charlie, but once he sufficiently motivated him it was done in a couple of days.

Vinnie doesn't see it as a 12-day technical issue, but a ten-day motivation problem followed by two days of "real work." With the realization that developers are lazy and self-indulgent, he now knows to keep pressure on his developers so that they'll do their work instead of goofing off.

Vinnie is suffering from the worst kind of confirmation bias, and will come to believe that abusing his people is the best way to get work done on time.

The stories are misaligned, and the take-away lessons are in strong conflict. There will be a downward spiral if neither viewpoint changes.

In this way, the world keeps turning and the stories we tell perpetuate bad theories about how people should work together. The gap between us widens with the social friction and mutual condemnation. How long before we lose all respect for each other?

Wednesday, September 9, 2015

Making Data Relationships Obvious

When you are writing tests you end up using literals or hand-constructed data objects.

However, using literals can obscure the meaning a little. Not horribly; most people can puzzle them out quickly enough, but you can make it easier on the reader.

In most of these tests, the values are pretty much arbitrary, but the relationship between the values is essential. For instance, when checking that no bonus is given when sales is less than quota, I could state that sales is 10,000.00 and that the quota is 9,900.00.  Pretty much anyone could tell that the quota is less than sales here, right?

But what if we made it really explicit?

     double quota = 10000;
     double sales = quota - 100;

This is how I like to roll. For instance, in python:

     event_date = datetime(2015,9,10)
     later = event_date + timedelta(days=10)
     earlier = event_date - timedelta(days=2)

And how about this alternative when you want to construct an object as a slight variation as another of the same type?

     origin = datetime(2015,9,10)
     later = datetime(origin.year, origin.month,

I think that building one object as a modification of another (by add/subtract/etc, or by unpacking one into the constructor of the other) makes the intention of the author clear.

Of course, if you modify the original object, the object constructed through relationship instead of literal will change with it. 

The easier maintenance is just a bonus you get for being an expressive programmer. 

Sunday, September 6, 2015

Sick of Eating: Planning Stress

In 2014, a group of Industrial Logic consultants planned a group getaway to help gel the team. We are a massively distributed small organization, serving the worlds biggest customers from four or five continents.

We had hired some new people, and we needed to assimilate together. At the cabin for a week, we could learn to work together.

We were in a remote location with internet access, each other, and the food we carried in. We would do real work (mostly proposals) and in doing the work learn where our frictions and strengths are. Ideally, it would lead to self-coaching and we could leave a fully formed team.

But What Will We Eat?

Food planning was where we ran into planning stress.

To begin with, we didn't want to spend days of effort on planning the food. Our time is expensive, and planning what we'd eat is not something we could afford days of effort on.  

On the other hand, we needed good up-front planning, because we couldn't really change our minds once we were there.

Different people would want different things (some vegetarian, some vegan, some restricted, other people omnivores and near-carnivores). Some liked to snack on fruit, others on olives, others cheese and crackers. Maybe we'd want tea, maybe soda, maybe beer, maybe fruit juice.

Having too little food or too little variety might cause clashes between people; some would have exactly what they want while others went without anything that they liked (or could eat). We didn't want to use this time to increase the dissidence between people. We had to be "fair."

Likewise, some were very concerned about sourcing responsibly v. saving money. Did it matter if the eggs were cruelty-free and free-range? Did the meat need to be grass-fed and hormone-free? Did coffee and chocolate need to be fair-trade? Did the politics of the store matter?

We would not have a second chance to plan it once the week had started.

We wouldn't know if we had it right until it was too late to re-plan.

The need to cover all contingencies, and we had to have a final answer up front.

That's planning stress. It's not a big deal, you would think, but as amateur event coordinators without professional help, the team put everything into the plan that anyone might need (or want) .

We ended up purchasing over US$500.00 in food.

The food was great. We had roasted vegetables, soups, middle-eastern fare, awesome pancakes, snacks, drinks, roasted meats, gourmet olives, cheeses straight from the Netherlands. By Thursday, we were simply sick of eating great food. We had prepared a whole turkey, and only sampled bits of it (out of curiosity and politeness, mostly) because we were so tired of great food.

The food we had left over would have fed a small village for a week.

We clearly overspent and overstocked, and as a result we had a pretty high level of waste.

By the way, it was a smashing success as far as creating closeness among the team members and producing good proposals. Something about cooking together and working together all day taught us to respect and value each other. I can recommend the retreat idea, but highly recommend using professionals for food planning, or at least establishing a reasonable budget for the team to work within.

How Does This Relate To Software?

This same behavior is observable in projects.

If you have to give up-front requirements and make promises on an 18-month project then you have to ask for everything you might want in the next 18 months.  It's hard to know everything that you might need, so you put it all in. After all, you want to be thorough.

Some features won't fit into the plan and will have to be dropped, so you'd better have something else waiting in the wings that has been carefully thought-out.

Of course, the client doesn't have clairvoyance either, so they don't know exactly what they'll need a year and a half from now.

We are told that over half of all software features produced by developers are never or seldom used. Sadly, we don't know (in advance) which features those are.

If you pick the wrong features or not enough of the right ones, then the product will not be accepted by the market or the customer. You won't know until acceptance if the customer really wants it (by which time your innovative new features may be commonplace).  You could do a great job churning out features for 17 months only to fail utterly in the 18th.

You can't change your mind once the project starts (at least not cheaply), and you can't know if you're right until after it finishes.

We might plan two years' worth of work into an 18 month project. Sometimes more than that.

Planning stress causes overload.

Just as we could have been happy with less than half as much food, most projects could be just as successful with fewer features, or with implementing less of each feature.

I consider "planning stress" to be made up of (primarily):

  • The period for which you must forecast needs
  • The time before you can find out if you're right or wrong
  • The need to be comprehensive
  • The costs of being wrong
Reducing scope or period would reduce stress, as would more frequent feedback.  Smaller batches (as are common in Agile methods) try to address this.

What if we only needed to plan for a month at a time? It is much easier. We can find out in mere weeks what a customer likes or doesn't like. A new feature that is not 100% what they want will result in customers asking for the next change instead of us having to guess. We can find out if people use the new features, so we know whether to abandon, expand, or defer more work in that area. It's only a month. We're likely to not plan more than 5 weeks of effort into a monthly plan.

What if it were only a week? What if we could release new software to some of our customers for comment every week? It's unlikely that we'd load more than 6 or 7 days worth of work into a 5-day week, and we'd be willing to make trade-offs and scope reduction this week, since we can vet our ideas at the end of the week.

What if it were a day?  A matter of hours?

John Tangney once told me "Continuous deployment takes all the stress out of building software."  I think he's probably right. Knowing that you can change your focus or change your mind about a feature at any time is very freeing.

Tuesday, September 1, 2015

Struggling is Not Lying

That Lying Hypocrite!

When you see someone talk about the evils of smoking and then catch them having a smoke in the back yard, the cognitive dissonance hits. Your brain hates cognitive dissonance.

You see someone talking about techniques for losing weight, tricks to avoid cravings, etc. Then you catch them mid-afternoon with a Hostess cupcake two-pack, a half-eaten bag of chips, and a Pepsi. That is when cognitive dissonance kicks in.

Luckily your brain has an easy answer to cognitive dissonance in the Fundamental Attribution Error. One attributes behavior of others to personality rather than circumstances. By reaching for judgment and blame, the brain quickly settles the issue: because person does does the opposite of what he says, he is a hypocrite. The individual is either self-deluded or dishonest, so let the shunning and shaming begin!

That's not necessarily how it works though.

Rather, That Brave Soul!

A person who struggles to change and suffers setbacks is not a hypocrite.

The dieter who binges on pre-packaged, mass-produced sugared fat is not a hypocrite. That dieter is a person struggling and sometimes failing.

There is so much more to this than "you say X but I saw you do !X."

I used to smoke. About two packs a day for around 10 years.

Toward the end, probably the last two years, I wasn't really enjoying it, but I enjoyed the withdrawal symptoms even less.

I liked sleeping, but I found that 8 hours was longer than my body was willing to go without a cigarette. I woke in the middle of the night so I could smoke, so I could sleep.

Doesn't sound like fun? I complained, but was hooked. I was a poor soul struggling and frequently failing.

"Inspiration" from Strong Quitters

Some people tell inspiring stories of putting down a pack of cigarettes one day and never looking back, never really struggling with withdrawal, never lighting another or taking a drag from a friend's cigarette, never inhaling deeply in a crowd of smokers, nothing. Just "I decided and that was it."

I think those stories are great. But I don't think we all experienced it that way.

Those "inspirational" stories are held up as "the way it should be" -- an expectation that one can make a simple decision and then never have any issue again.  When poor saps like myself hear those stories, and don't experience such a painless, seamless transition then we feel like we have failed.

I "failed" to quit smoking several times. I even "failed" to cut back. People would be happy to tell me that it was willpower, and I needed people to hold me accountable, and it was a lack of discipline.

In other words, not only did I fail, but I failed because of the kind of person I am -- a weak-willed loser.

Think about the fixed mindset message here: you are the kind of person who can't quit because quitters are better than you are.  In other words, I would have to have a personality change in order to become a winner who could walk away without symptoms or else I'm doomed.

The last thought I needed in my head was that I can't change, and trying will only show me to be the inferior specimen that I am.

Being the Weak Quitter

Even though I didn't want to smoke, I still smoked. I just didn't like it much.

I came (again and again) to a decision to quit. I looked for reasons and opportunities. I struggled and fell back a lot.

A bit later I started dating Libby, who was to become my wife only months later, and asked her support. Libby didn't smoke, and that made my smoking even less desirable.

Good Lord, it was tough. The "crawling lungs" and the nicotine fits. Worse yet was the doldrums and inability to feel joy;  nicotine, I'm told, replaces dopamine, so the body quits rewarding you for good decisions and actions.  For some time, stopping to take a smoke break was my celebration, and the only way my dopamine receptors were activated. I was unable to take joy from food, from activities, and from work.

I slipped up. Sometimes I was out with the other consultants and was the only one not smoking... at first. Eventually it was simply too much for me and I mooched a cigarette or sometimes a few.

Most people would experience the "what the hell" syndrome about this time, feel the satisfaction from that cigarette break, and of course succumb to the social sense that struggling with smoking meant you weren't really resolved and were in fact a weakling who couldn't quit.

Those of us who made it through this stage all realized that we hadn't quit quitting. We just screwed up. It got too hard for us, and we caved in that time, but in the morning we were still cigarette quitters. We just weren't really good at it yet.

It took me a little over two years to reach the point where the smell of burning tobacco didn't incite any cravings, I was able to take pleasure in food and work and accomplishment, and I no longer had any lingering urge. I told my wife "okay, I've done it. I'm a non-smoker now."

I'm an ex-smoker for almost 27 years, the first 2.5 of those saw increasingly irregular failures and ultimate success. I'm told my lungs are probably snow-white healthy and free from tar now. Now I'm old enough to have other reasons to sleep poorly, but cravings are not a part of those.

So What?

That's a nice story, maybe, but what the heck is it doing on the Agile Otter blog? Isn't this a software blog?

Well, yes it is.

The point is that organizations and people are also addicted through years of habit including abuse, blame, control, and success theater.

Maybe they've got a real powerful three-packs-a-day waterfall habit, or maybe it's overtime addiction, or belief in motivation through fear.

Maybe they've got a bit of Stockholm Syndrome in that they really have made peace with outrageous schedule pressure and cubicle life and isolation from each others.

Maybe they've given up being teachers and become filters instead -- consumers of people rather than producers.

Whatever it is, they have relied on it and have attributed it with their successes. They have been at peace with it.

And now circumstances or choices have demanded a change.

These organizations may be trying to move to Agile methods. But they're struggling. The people in the organization are struggling. They'll make mistakes. They'll backpedal and sometimes backslide.

The most important thing when struggling is not to stop. You might fail today, but this isn't your last day. You can always give up trying next week, so keep at it now.

Struggle on, brave soul. Let's not quit quitting.

And the rest of us, well, we can give brave souls a little grace. Maybe if we quit kicking the losers, we might see more winners.