Monday, October 15, 2018

Q and A on Velocity, Part IV

In our last installment, part III, we talked about the reality of reality and contrasted that to the made-up-ness of schedules and estimates and promises.

Today we take a deeper look into one element of that dichotomy:

A: The schedule is a best-guess, but there is a real promise behind it.
B: How does that affect the rate at which things can be done?
A: Can I put more people on it?
B: Maybe, but cf Brook's Law

There is a reality to the made-up-ness of schedules, too. In this exchange, person A is reminding person B of the fact.

Promises are real. Trust is real. Keeping promises creates, sustains, and promotes trust. Real life organizations run on trust.  Plenty of business leaders (and one agile aquatic mammal) have spoken and written on this at length. One of my favorite authors on the subject is Stephen M. R. Covey (AKA "Covey the Lesser") with his book titled The Speed Of Trust. Also, see economist Ronald Coase's work, where he explains the lower transactional costs of trust.

And yet, for all of this, reality doesn't do what we want it to do. Things still also take as long as they take.

Rock, meet hard place.

If we were installing drywall or carpet, then the work would be partly skill and mostly effort. We could get more drywallers or more carpet-layers and we could do more rooms at the same time.  We might even be able to do one room at a time faster, provided on how well they coordinate.

But no. This is different. Programming is a chain of logic that is fed by and feeds into many other chains of logic. The parts are not as independent as we think, and not understanding the larger context (and the flaws in the parts in the larger context) will lead to many defects.

I once switched a bit of code from a bad way of doing work (building JSON strings by concatenation) to a more proper use of a JSON library, and took a system down for a little while. Sometimes the system depends on the work having been done the way it was -- the wrong way -- in order to function. Things stick together in a weird way.

Bringing in developers who don't know the way that the code works doesn't help. Mob programming or pair programming with people who know more about the different parts of the code certainly does help. Adding knowledgeable people to the effort does lead to a better result, but doesn't necessarily make the work go faster.

Brooks' Law is the observation that adding people to a late project makes it later. This has been studied and documented at length, and anyone wanting to try to accelerate a project by adding people should beware. It's not impossible to add people to a project, but often a flood of new workers who don't know the system will make it FAR worse.

These are inconvenient truths, which press us to look into more promising alternatives if we want to see work delivered to an all-to-real schedule.

Friday, July 27, 2018

Q and A on Velocity, part III

In Part II, we talked about velocity and the (glossed-over) line about making it easier to get work done instead of pushing harder.  A was asking if changing the units used in estimating would help and, of course, it doesn't.

We pick up from there this week with a tiny snippet of conversation that touches on some big ideas:

A: Then how can I get my 30-point velocity?
B: What if there isn't a way? Maybe you need to need less?
A: But the schedule....!
B: The schedule is made up. How long it takes is real.

Software estimates are often wrong.

Quite often they're off by over 200% on specific items. There is a very good reason for that, and that is that we aren't given uniform standardized work items and a standardized process. Nor can we be. If the feature the client wants has been written already, we don't write it again.

Software developers don't repeat themselves. Each problem and each solution is (a little bit) unique.

As such, each estimate includes not only effort but also a risk (of breaking something) and uncertainty (need to learn something).

  • How long will it take you to learn how to do something you've not done before? 
  • What are the chances that adding this new feature will damage performance, suck memory, or complicate deployment? 
  • Have we discovered every "touch point" or is there some screen or report or calculation that needs to be modified because of the new data or procedure introduced by this change?
  • What is the likelihood of some other unintentional or unforeseen consequences, perhaps due to different configuration options? 
  • Can we easily understand the code that we will have to be changing, or will it take considerable effort to unravel the original intent and comprehend all the side effects? 
The risk element piles up greater and greater as a system grows. All new functionality, and especially functionality 'shoehorned' into place (quick and dirty hacks "to get it done fast") will increase the chance that something bad may happen in some dark corner of the code. Projects slow down over time due to this. 

When systems grow, and there is insufficient automated testing, then the ability of a developer to recognize that a new change has caused breakage is limited. 

Many software shops do a poor job of mitigating technical risks, and often blame them on "not having good enough programmers" when breakages inevitably occur.

Sometimes more stories are done than expected because the risks didn't materialize and the learning was easier than anticipated.

Other times, unexpected risks materialize and stories blow up to several times their original estimate. But the same amount of work is being done every week.

Estimates are made up. They were to someone's best guess about the amount of learning, the amount of typing, and the amount of risk that a story entails. Still, they can be off by 250% or more.

Schedules tend to be based on estimates, although quite often this is done backward so that the estimates are based on the schedule.  

The problem statement "we need 30 points per sprint" suggests that the original schedule and estimate were made based on a desire to have a particular thing finished by a particular time, believing that a high rate of accomplishment would be possible.

Here, where the rubber meets the road, the actual work is not happening as fast as the original scheduler hoped that it would. This leaves the manager in a tough spot since the actual rate of completion is about 2/3rds the anticipated/hoped rate of completion. 

There is a very real risk that a full 1/3 of the project cannot be completed on time. 

A smart software manager understands this, and so prioritizes so that the most important features are built early on and delivered soon. That way, when work has to be descoped, it is the least important work being dropped. 

This means not only sacrificing some stories but possibly the less-interesting parts of every story (cf Story Mapping and Example Mapping, Walking Skeletons, Evolutionary Design, etc). 

A smart team will find -- through feedback -- which parts of the project should not be built at all. Often people over-specify and over-design. Sometimes the presence of a simple solution reduces the need for a comprehensive one.  This is built into the agile manifesto (called "simplicity", defined as "maximizing the amount of work not done") and is crucial to all agile methods.

If we can need less, we can deliver sooner.
If we can prioritize well, we can sacrifice lower-value work.

Feedback from customers improves our prioritization and our ability to descope intelligently but requires us to release code to them early and often.

If developers are pushed to provide brute-force, quick-n-dirty solutions then it increases the cost of change due to more difficulty researching changes and more difficulty spotting breakages.

With enough risk pushed into the code, it may become intractable. The team may have to stop producing new features to clean it up. Nobody wants that. It is faster to write clean code with good automated tests to being with than to end up spending 80% of developers' time cleaning up messes and defects.

Which again brings us to the hard truth in this installment:

How long it actually takes is real. Estimates are made up. 

Blaming reality for not matching fantasy isn't useful, and blaming people for making up unrealistic schedules is not helpful. We are where we are. We have to move forward.

It leaves us with a bit of optimistic pessimism: if this work cannot be fully completed, what is the best possible release we can make given the resources, time, and scope at hand? 

See you back here for Part IV.

Wednesday, July 25, 2018

Q&A on Velocity, Part II

See Part 1, in which we present a deep truth about velocity and story points. A's team has turned in two sprints, with velocity of 19 on the first and 23 on the second.

A: Okay, but my next sprint needs to be 30 points.
B: What has changed to make a point be 1/30th of a sprint?
A: We just need it to be.
B: Then improve something significantly so it becomes possible.
A: Can we just try harder?
B: There is no evidence that works.
A: Then story points aren't useful.
B: We could have started with that agreement.
A: Let's use real hours then!
B: Not better.

There is a primary truth being described here, and that is that velocity is not a knob that one can turn. I addressed that previously in another blog post, some time ago.

Velocity does not raise because people try harder.  If that were so, it would be because people were (until now) withholding their productivity and waiting for you to ask for it. It's unlikely, but if it were so then one would have to wonder why they had been withholding; what system of work required them to make such an adaptation.

When raising the velocity is given as a task, a team will usually inflate the estimates to bring up the points, or award points for every activity in order to bring the number up.

This brings to mind the Hawthorne Effect, Goodhart's Law, Campbell's law, and (most upsettingly) the Cobra Effect.

It doesn't raise due to changing the unit of measurement to days, hours, minutes, points, lollypops, NUTs, etc.

About the same amount of energy is expended from week to week and from day to day, and things take however long they take. Needing more doesn't make the work any easier or faster.

However, notice the line I italicized, above.  The people in the hypothetical conversation gloss over this line and don't return to it for a while, but it's there.

Here is something S.R. Covey said about making it easier to get work done:

I view it as effort provided over effort required.

If the fraction equals 1, then you were effective in getting the job done. But at what cost? If we have work that requires a lot of effort, then we can only accomplish it by putting a lot of force toward getting that thing done...

... wait. That's not true.

The other alternative is to reduce the amount of effort required by the work, and then we can complete it easily.

Increasing effort doesn't scale, and doesn't sustain. It is a great way to lose people.

Decreasing difficulty of work scales like crazy, sustains effortlessly.

So, if we want more work done we need to stop messing with the measurements and demanding more effort from our hard-working people and, instead, work on reducing the difficulty of getting work done.

Most software organizations have policies and practices and flows which seem purpose-built to slow and prevent the release of software. There are queues and wastes at every turn and most of them outside of software development. Easly 90% of most policies are preventative. Few provide acceleration or support.

So if we are focused only on raising the top number, we're likely to defeat ourselves.

Managers should take some time to read John Gall's The Systems Bible, which tells us two things of note:

  • Human systems run at around 5% efficiency
  • Systems tend to oppose their own best function

See you in Part III.

Thursday, July 19, 2018

Don't Be Dreadful

A few weeks back, I published a blog about people complaining in a company.  The article has received a lot of attention and love, and I appreciate all of you who retweeted it and linked to it and Instapaper linked it and recommended it in Pocket.

I completely stand by all that I said, and I think it's worth paying attention to.

Today I want to talk to you about not complaining. Well, just a bit.

Actually, maybe I'm going to talk about how to do it better, since I've been working on learning that bit.

There are things we know about human interaction and human memory, and some of them seem pretty crucial to anyone who wants to make a change in their culture (org or otherwise).

You see, people remember the way you make them feel.

The fundamental rule for any change agent has to be:
Do Not Be Dreadful
You see, part of your memory mechanism involves your amygdala and your hippocampus. These are two parts also very much involved in your emotional experience. But you don't have to know much about neuroscience (as indeed I do not) in order to appreciate that memory stores not only data but also emotions and sensations.

Remember when you last cut your finger or barked your shin? Do you have more memory about how it felt, or what color the walls and ceilings were in the room, it's location, and the full set of people in the room when it happened? Odds are, there is more feel than fact in your memory -- or else that the feel precedes the facts when you recall the event.

Were you ever afraid? I bet you have a number of memories filed under "fear" that aren't easily accessible to you through other categories. Your filing system is largely emotional.

Likewise, there is probably a sub-folder for the times you were really afraid at first, but then had a flood of relief when you realized that the fear was totally unfounded. You mistook your coat on the coat hook for a stranger in the room, you thought you were going to fall when you were in no danger, that rustling behind the bush turned out to be a bunny rabbit. The relief is a powerful feeling.

Think of someone you would like to see again.  Pleasant feelings, sadness at the distance between you, nostalgia? These tend to precede any concrete memory of what they've done or even what they look(ed) like.

Likewise, could you list one or more beloved mentor in your life? How do you feel first when you think about them, even before you list one thing that they told you, however life-changing it was?

Is there someone you would like to avoid? Ah. Negative feelings, huh? Could you make a list of four or five right now? I'm betting you could.

Now if the most dreadful of the five came to you and told you that you're parking your car incorrectly, or wearing colors that don't work together, or holding your pen wrong... how likely are you to receive this information with joy and gladly correct your behavior?

What were the dreadful traits of the people you found dreadful?

  • Fault-finders
  • Nit-pickers 
  • Self-involved
  • Self-seeking
  • Self-pitying
  • Kiss-ups
  • Bull-in-a-china-shop
  • Dismissive
  • Bossy
  • Rude
  • Dishonest
  • Disdainful
  • Trolls
  • Argumentative
  • ... other...?
I would bet that just reading that list may have brought up unpleasant memories of people you've worked with. A few of those may have reminded you of your younger, less polished self. 

We are unlikely to change to satisfy someone who doesn't seem to respect us or have an interest in our betterment and happiness.

We are rather more interested in changing to improve our lives on the advice of people who have shown a genuine interest in our lives, careers, and accomplishment. 

If we are to be change agents, if we decide that we want to make a difference by improving the lives of people we come in contact, if we decide that we want to be a part of the mission to "make people awesome" then we need to recognize that this is firstly relational work and that all the things we say and do have as much emotional content as data. 

If we are right, but we are awful, then people will probably not engage with us in a meaningful way. Our conversations will likely to be filed under "things that awful person said" instead of "things that will help me."

If we're awful enough, we will serve as an inoculation against good ideas and advice. People will have built up an immune system such that when a statement made by some other change statement reminds them of our interaction, they will shut down the other person. This immunity to change may last years or decades into the future.

It is absolutely crucial for a change agent to be heard. 

We are heard when we are welcomed and invited. We are more likely to be ignored when our presence is dreaded.

If our words and ideas are to have any good effect on our world, then it falls on us to make it easy to listen to us and easy to hear our perspectives, ideas, and (when absolutely necessary) advice. 

In other words, we must never become dreadful to people who need our help. 

Tuesday, July 17, 2018

Q&A on Velocity, Part I

Having had many conversations about velocity (and many blog posts here and at the Industrial Logic Blog) one day I decided to write up an example of the conversation as if it were happening between two characters named A and B.

The first question asked by A was the first question about story points that a younger agile otter asked in his first XP project.

Most of the questions were asked by my younger self at some point or asked by someone I have worked with.

By the same token, the answers came from myself and people I know too. I've internalized these conversations to the point that I'm not sure what questions were mine and which were asked of me, and which answers were original and which came from mentors (managers, coaches, developers, etc).

Suffice it to say that I'm represented (at various points in my journey) by both the questions and the answers. As such, the point of the dialog between A and B is not to humiliate or pillory either A or B. The questions are pretty reasonable (most of the time) and the answers are not only honest but reveal deeper truths about software development and agile methods -- most of which one cannot acquire except through years of experience or mentoring.

At no time is it to be assumed by my publication of this series that I recommend using story points or velocity. I do not.  Even so, if people are using them, they should understand them at least until they realize that they are better off without.

So, here is part 1, annotated.

A: How long is a story point in real time?
B: How many did you do in your last sprint?
A: 23
B: Then, for you, it's a 23rd of a sprint
A: But the time before that it was 19
B: At the time it was 1/19th of a sprint.
A: But how long is it really?
B: We've determined that.
This was a major breakthrough for me early on. I didn't realize that roughly the same amount of work is done every week. Story points are a rough sizing of work, not a measurement.

I was once informed that every estimate involves not only effort but risk and learning. Risk and learning are often the larger part of each estimate. So when someone assigns a larger estimate, it is usually because they don't know how much they're going to have to learn to do the work or because they don't know what the risk is of it having wider unwanted effects on the schedule.

Many developers and managers refer to stories "blowing up" -- where it was estimated as a 2, but in reality, it was more like an 8 or 13 or 21. It's hard to know where the risks and learning will occur.

Sometimes a story assigned an 8 or 13 turns out to be easier and less risky than imagined, and the story is done in the time it would take to do one that would have been assigned a 2.

This doesn't mean that the team is doing a bad job, it really reflects more on the variability of the work items instead of the lack of consistency of the team.

When the team is not familiar with the source code of the project,  it is more common for greater numbers to be assigned and it for the stories to "blow up" or have defects. That's what happens when you don't know your way around.

But either way, the size of a story point isn't very meaningful -- it's a guess to begin with, and its "real size" is not only knowable in arrears, but is also variable. It is a unitless unit of measure, a bit of nonsense that people sometimes find useful for capacity planning.

It's almost always misused. An option is to stop using story points.

I'll see you in Part II

Thursday, July 5, 2018

The Scatter-Gather Method of Software Development

There is a certain theory of agile development which is built on factory thinking, using division and management of labor to accomplish large projects.

The Plan

You have a big job to do?


  • Divide the project into pieces
  • Resource the project (acquire the right number of "teams")
  • Assign pieces of the project to "teams" 
  • In the "teams", a lead character will divide the pieces into smaller and smaller jobs
  • The small jobs will be assigned to individuals who work for the lead


  • Individuals complete their small jobs
  • The small jobs are integrated/combined/summed by the lead
  • When small jobs are done, the lead delivers the finished work of the "team"
  • "Teams" who completed the work are released
  • The project office then combines the parts
  • The integrated, completed project is delivered

Please note that there is an inverse pattern here: "Teams" are gathered during the scatter part of the process, and scattered during the gather part. But let's not focus on that right away.

Why do you put quotes on "team"?

A team is a group of people aligned on common goals, who work together to achieve those goals. Such a team works together every day, and each member works for the best team outcome. That is a team without quotes.

There is another use of the word, though. In many organizations, all the workers are individual contributors who are encouraged to get their own work done. 

They might occasionally offer advice or be a "second pair of eyes" (cf Rubber Ducking) for another person, but the only real connection between them is that they have the same boss. 

"Teams" (quotes included here) are an org chart conceit. 

I find that scatter-gather style work requires exquisite planning and estimation, and for one person to be tending to another person's assigned work (remember it's assigned to individuals) puts the individual's (aggressive) schedule at risk. 

Each person absolutely must complete their own piece of the work on time, else the whole schedule cascades into failure.

Quite often, the manager/lead is posted to act as a "blocking troop" to punish any person who falls behind. 

Often leads are chosen for their ability to operate as an individual contributor. 

Sometimes leads are chosen for their exquisite planning skill. 

Occasionally, a lead becomes a lead because they have a penchant for working as blocking troops. 

In every case, it is a token of respect to be "raised" to the level of a team lead. Different organizations and sub-organizations just respect and promote different qualities.


In theory, when all the individuals finish their parts, then those can be integrated and tested, and the parts passed up the tree for integration and testing at a higher level, and then finally the organization will resolve all the integration problems and mismatches and release the software.

Ideally, there will be no integration problems because of the upper-level project team's exquisitely detailed design and planning. People are often promoted to this level because of past success and because of their talent and passion for planning. The goal is to have everything worked out up-front so that integration problems do not happen.

But they do happen. They almost always happen. They're happening right now.

There are always some misunderstandings, some kind of design drift, some platform issue that had to be worked around and of course some of the small jobs took longer than anyone expected. Some late parts had to be left out (temporarily) or revised during development (thus damaging the validity of the grand plan).

How do scatter/gather organizations resolve those problems? Generally speaking, the people at the project level don't have the technical skills to resolve these problems.

Luckily, even though they tend to run as project organizations (a convenient but prevalent organizational conceit) "teams" tend to be composed of full-time employees working long-term on projects that tend to be related to a single code base. Therefore, the members from the original "team" may still be present, and may still be on the same "team."

Integration problems are addressed, then, by temporarily borrowing-back the members from the original "team" who can diagnose and resolve issues.  Once the problems are resolved and the system is sufficiently tested, then the original "project" (really a product increment) can be "released" to customers.

Remember that integration problems are treated as exceptions.

That integration problems always happen in scatter-gather is only because the planning and detail were not exquisite enough to avoid the failure, and scatter-gather is reliant on predictability and exquisite scheduling. Without sufficient up-front planning, the project will not come in on time with full scope completed.

And of course a lot of projects don't come in on time with full scope (which suggests that a more agile approach is appropriate), but the scatter-gather system is so reasonable on the face of it that many people think it the only system that could possibly work.  Sometimes people say "at scale" or "at enterprise scale." The goal of "scale" in this sense is to produce a product using several hundred or thousand programmers simultaneously and keeping them all busy.

Some organizations have made inevitable late integration problems part of their standard process by adding hardening sprints. "If you can't fix it," we are told, "feature it."

Busy Enough 

One of the problems with working at this scale is that programmers are not cheap. Even the cheap ones are not cheap. There is a constant "burn rate." An hour of time costs the same whether the teams are productive or idle. And it's a VERY LARGE NUMBER.

If you are paying, and it's a VERY LARGE NUMBER per hour, then it's important that all the people ("resources") are kept productive at all times. This isn't snark, or hyperbole, or foolishness. It's a VERY LARGE NUMBER and you need to be sure that you're getting value for the cost of that hour.

So when teams are released from one project, it's keen to have them starting another ASAP. This is a tricky bit of "scheduling tetris", but many managers above the project manager level have significant skill at scheduling. Sometimes, to make the scheduling work, they have to shuffle teams in or out of a project where the team "members" have no familiarity with the code base or domain, but we know that given time a developer (QA included) can develop skills in any code base or domain. It's a matter of good communication and management, which the "leads" should be able to handle or they shouldn't be leads.

When I first began to manage teams, it was in a scatter/gather organization. I was told that the first rule of management is to always make sure all the team members have enough work to do.

I was given the VERY LARGE NUMBER which is the hourly burn rate, and reminded that an idle team costs the company many many digits of loss per minute.

Oddly, I have no idea how much value or income the team's product produced per hour, day, month or year or what the ratio of cost:value was for the project. I was instructed to focus on the costs and get the maximum quantity of work possible to justify the burn rate.

I've heard this First Law repeated many times. It is a corporate mania that the profitability of the organization will plummet at a rate of $VERYLARGE/HOUR if employees are not busy enough. It could destroy the company (and certainly would, if the burn rate exceeded the rate of income for even a relatively short period of time; days, weeks, months. It's inevitable).

This First Law is one of the problems with the hardening sprint. The staff in a hardening sprint end up waiting for something to be broken. Idle resources are expensive, and people must be kept busy, so hardening sprint staff tend to be part of some other scatter/gather project and likely on the critical path.

In other words, the hardening sprint is usually another organizational conceit.

Some Flaws 

Since everyone must be busy enough, by the time an integration problem is visible (at the end of the "gather" process) most of the people who worked on the code have moved to other projects in order to satisfy scheduling Tetris.

Also, as a result of "schedule Tetris" the project code is written partly by people who didn't know the code base, or the domain, or the development stack. Because they needed to be productive and to stay busy, they did the best they could at the time. Naturally, there are some defects, integration faults, inconsistency, and schedule slips.

Errors are the natural result of putting unfamiliar hands in complicated code.

The people who can fix the problems are the people familiar with the system as a whole, and those familiar with the code that was written. Of course, they're not on the "project" anymore, and may not even be familiar with the code they wrote anymore. They've moved on.

To get the problem fixed, some of them will need to be pulled out of their new, exquisitely planned and scheduled project. They will be brought back for some time (period unknown) to the suffering complete-yet-non-working-so-unreleased project.

This puts the new project at risk, which runs the risk of cascading schedule failure.

Often the risk to the project schedule is such that more teams are brought to bear (also often unskilled in the development technology, unfamiliar with the code, and new to the domain) to try to make up for lost time. These teams are likely to introduce similar failures in the new project, adding to the integration risk.

And the increased integration risk pulls more resources into the hardening sprint, putting another project at risk of cascading schedule failure, and a combination of scope reduction and staff increase is brought to bear again.

Either a point of equilibrium is reached, projects are canceled to relieve the pressure, or some other form of hilarity ensues.


Projects are late, schedules have cascading failures, "team" members are unhappy because they can't do their best work rushing around in the unfamiliar code, everyone is frustrated that "teams" can't avoid making errors and "team" members don't help each other to learn to work better.

Managers are frustrated with descoping work to try to get projects back on schedule, with the frustration of trying to keep up on the status of each "team" member, with never knowing if the system will be delivered on time, with the nagging sense that the team is missing something or the plan is wrong in some way that will cascade into failures.

But still. Still. Even in the face of years of struggle and repeated near-catastrophes and occasional failures, they are convinced that the system is entirely workable and the problem is either:
  1. they couldn't plan and design well enough under the circumstances
  2. circumstances arose which shouldn't have, and couldn't have been predicted
  3. the plan wasn't followed well enough this time and next time should be better
  4. our people just aren't good enough
Scatter/gather seems to be the only system that could conceivably work (at this scale). 

It's a tremendous act of faith, and the organization doubles-down on faith in the face of repeated failures. Scatter/gather must be made to work. We just have to do it better.


Of course, much of the world has developed mature practices which use continuous integration to surface problems early, collaboration to resolve problems quickly, and using evolutionary design so that the product is runnable on day 1 and every other day.

A lot of people don't even use projects to build product increments. They add features one-at-a-time or one-"epic"-at-a-time. They build release candidates every day throughout the project. Some of them actually go live with their product increments several (to hundreds) of times a day.

I know it sounds like heresy against the One True Way, but it's still so.

I know it doesn't sound realistic. How in the world could you do this in a scatter/gather organization? Without screwing up the schedule Tetris?

And to be fair, you couldn't.

You'd have to give up the faith. You would have to give up your core identity -- you wouldn't be a scatter/gather-based scheduling-Tetris organization.

You might even have to admit that the old system that you spent (VERY_LARGE_NUMBER/hour X for N years) on is not very workable.

There are often stiff penalties for being the first one to speak heresy against the Current Corporate Way. Worst than if you'd violated the First Law. Worse than if you failed to deliver. You could actually lose your position in the hierarchy, which is the Primary Topic in a large organization.

Still, a lot of companies work alternative ways and have for decades.

Keeping the Faith

But if you have great collective faith in scatter/gather as the only possible answer, alternatives sound ludicrous and couldn't possibly work in the real world.  Anyone who thinks that they could build a working system at scale without a scatter/gather plan must have lost touch with reality -- lost the faith -- possibly their whole way of working is a peyote-inspired fantasy.

Denial is the first step in avoiding responsibility, and humanity has found a lot of success in denying facts for decades in order to maintain their conceits about how the world works. I can recommend this strategy. It keeps you from having to change right now, and if you discredit heretics then you might not have to hear from them again.

I recommend it if and only if your goal is to continue, undisturbed, in your current beliefs.

And you have supporters in the industry, so that's nice.

The true believer in scatter/gather projects, schedule Tetris, and other organizational conceits can find people in the world who are happy to sell you agile frameworks entirely compatible with your way of working.

They will also gladly rent you consultants to put the processes into place and certify you to be practitioners of the True New Way of scaling.

They'll even give you the prestigious "Agile" title to adorn your press releases and recruiting posters.

But maybe, just maybe,  if you've suffered enough for your faith and find yourself filled with doubts, you might consider some of the alternatives.

Wednesday, June 27, 2018

Peace and Curiosity against Righteous Indignation

All anger presents as righteous indignation. Have you ever been angry and not convinced you were right to be so?

It is only in retrospect that one realizes that one was in error, with embarrassment and shame.
Maybe being angry makes us too sure, too certain of our view of others, too unquestioning of the humanity of others.

Sadly, righteous indignation is a powerful emotion and addictive. 

It leads to a lot of victim-blaming. If those people didn't make us mad, then they wouldn't have to deal with the consequences of making us mad. This is straight out of the abusive spouse/parent playbook. It feels righteous, it sure seems like righteous indignation -- while you're in it. Then come the apologies and then another relapse.

It justifies acting badly. When we use force, bullying, pillory, public humiliation, verbal abuse, defamation ... well, that's okay because we are the good guys. It's okay when Batman takes the law into his own hands. It's okay when Superman drops someone's office building on Luthor. It's okay when we bomb cities where bad guys are hiding. It's all fine because good guys get to do bad things in the cause of justice.

Although, it's hard to tell the good guys from the bad guys when their methods are identical, isn't it? 

An unexamined righteousness is a dangerous thing.

What if our anger is only presenting as righteousness and comeuppance, but is based on a misread of our circumstances or other people's motivation? Where is the curiosity, openness, discussion, dialogue?

How fast are we to label a villain and search them out for signs of villainy?

And what if we're only a little right, and the so-called villain is not set in their way but willing to be converted? Does our crusade drive them into greater "villainy" as it feeds their sense of being victimized unfairly? Doesn't it activate their righteous indignation?

Oh, that sounds like today's social media. And all other media too. 

Welcome to the age of outrage.

"Social" media (so-called, though it tends to be a shouting factory)  is full of people sloppy drunk on outrage.  Often, being angry and venting that anger is all the action that is taken. Abusing and bullying to "make them suffer for their crimes" masquerades as helping.  It's likely more about revenge and sharing pain than making a change, and unlikely to create any change. It's pretty good at creating animosity, broken relationships, lost opportunities, and enemies. So, you know, if that's "a better world" then I guess it is positive action.

I have found that outrage, especially habitual and recreational anger, make my life less creative, happy, useful, and meaningful while also not leading me to make any real change in the world (only enemies).

This is why I have been on a multi-year journey to rid myself of habitual anger, recreational anger, and worry.  

Strangely, I find I'm more likely to take action out of compassion for others than out of outrage and anger.

When I'm angry, I crave a victim and an opportunity for a violent act (even if it's just angry words).

When I care, I look to help.

I know it's not my job to tell other people how to think and feel. So I'm just sharing what works for me and inviting everyone who is of a mind to listen and consider alternatives.

Maybe we could all be less sure, less angry, and more busy looking for allies and partners and friends rather than scouring social media for enemies to shout down.

Sure, that's sensible, though not everyone who is sloppy drunk on outrage is looking to be sensible.

I don't know how to talk sense to a drunk. I have to instead look for opportunities to talk to the sober, or those who are looking to become so. Looking for kindred souls seems better to me than shouting down angry people.

You've come this far, so maybe you and I have just found each other.

How are you doing? How can we get to know each other? What interests you?

How did you escape your outrage and start to take responsibility for yourself and others?
Do we need a hashtag?