Friday, November 13, 2015


Over at Reddit there is a discussion about my Stop Per-Person Swimlanes article at Industrial Logic.

This surfaced what seems to be a common misunderstanding.

Some people think that the board was designed to facilitate public shaming.

It's to motivate members in a team to work harder. When your personal progress and responsibilities are put on a clearly visible chart somewhere it's a bit different than a sea of todo's some of which are labeled with your name.
 There are a lot of answers, agreeing or disagreeing (mostly disagreeing).  This one stands out:

It's different. Whether it's a good thing or a bad thing is EXTREMELY unclear. 
My take is that in most corporate environments that is a BAD thing. Why? Because, rather than thinking about the overall health of the code, coder's main concern is getting that ticket closed [emphasis mine - tro]. 
Which is a very straight path to the quick codebase degradation. 
Meanwhile, your velocity is high and management is happy while the project is quickly running into the ground.

This brings us to our topic of the day: Plate-Emptying.

Plate Emptying - However silly it sounds...

Plate-emptying describes any behaviors which aim to increase performance in the small by minimizing the touch-time for each subtask performed.

I have witnessed it wherever there is pressure put on people to "finish quickly,"  or to "increase velocity" without any sort of work off-loading. It's especially visible where issues of quality are downplayed compared to speed task completion.

A pathological made-up story:
Imagine your dentist's office is running behind, so the oral hygienist, aware of the exceptional need for high productivity) gives you a toothbrush and tells you to go brush your teeth, then moves on to the next patient. 
Or worse, imagine that the hygienist skips your teeth entirely and gives you the bill, because collecting fees provides value to his employer. Why not cut out the unnecessary motion and get down to money? 
Imagine that the dentist who heads the practice gives that hygienist a raise, and berates the others for being comparatively slow and unproductive.

Now imagine that two of the other three hygienists follow suit, and three days later the one hygienist who takes the time to take care of patients is sacked.

Yes, that's awful and it's silly. But stay with me here, because this is how many software companies operate.

But... this is SOFTWARE!!!

Yes, I know that software development is rumored to be a low-stress occupation, pleasant and pastoral with good rates and plentiful employment. That is not how corporate programmers experience it. In fact, their lives seem to be full of death marches, which are driving people crazy with stress.

Managers are in a horrible crunch most of the time. Big customers demand, and therefore are promised, a lot of work.

In software, everything is ASAP (or presented as if it is, to keep "motivation" high).

True Story: 
Managers had a significant defect backlog (tens of thousands) and were talking about two teams. 
One team is methodical, and sometimes could take a day or two to fix a defect, but they were always truly fixed and passed through testing and to deployment without any issues. 
The other team emptied their plate quickly usually in less than a half-day, but often had to revisit the same bug several times because their fixes didn't always really work or sometimes had troubling side effects.   
After deliberation, the managers decided to give the lion's share of bugs to the latter team because "they get things done faster." 

I suppose "done" in this case refers to plate-emptying, not full completion and deployment. All the numbers showed that tasks given to the "fast" team took considerably longer to deliver due to the rework involved, once you count in the round-trips to QA and the rework.

If we use an industrial era kind of thinking, then we are limited by the speed of the slowest component in the chain, and since apparently software is the work of people, it is obvious that we need all the people to do their work faster.

Surely, if everyone works faster, the whole line will be moving at maximum speed, and therefore the product will be done as soon as possible (in software, everything is ASAP!).

The clear, simple, obvious answer, then is to get each person to do their fastest work. We will hold them to a short turn-around and reward them for reducing their time budget for the work being done.

And since there is too much work,  we need to start it as soon as possible by cramming it all into a queue until development staff (coders, testers, etc) are split between several (sometimes dozens) of tasks. They will "just have to multitask."

What could go wrong?

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

Note how this theory of "go faster by rushing everyone" avoids looking at workflow and queues and Little's law, and all the things we've learned about multitasking and cognitive function, and the basic principles of knowledge work and Lean management. This is conveniently, obviously, simply, horribly wrong thinking here.

Nobody was counting the system's time, only the worker's time.

Nobody is counting the wait states, only the touch-time.

Lean thinking teaches us to watch lead time, and to understand the system. That keeps our optimization processes focused on actual bottlenecks and constraints.

However, functional managers (over programming, over testing, over documentation, etc) don't have authority or influence over the entire system, and tend to focus on their realm of influence -- their specific function. I can hardly blame them.

So what happens?

When a designer has too much work on his plate, he can always "abandon as done" when he has a rough idea, a couple of sketches, a wireframe, a spreadsheet, or maybe a proof of concept in powerpoint or visual basic. That's close enough, and we need to get this off his plate (and onto someone else's). Sometimes it's "close enough" and developers will figure it out but if not, it will come back from UX or Acceptance testing and can be handled then. If it gets out the door and customers don't like it, we can handle it with customer service and fix it in next release (taking it off the designer's plate for weeks or maybe months).

An architect's best tool for plate-emptying is to just say "no," since it is faster than evaluating an alternative, and after all there is so much to do.  Sadly, the architect is usually valued for how many things she has in process at once, rather than for her rate of completion or overall impact on the project. It hardly makes sense to defer, delegate, or refuse when one is being graded on how busy one is.

A developer will probably short quality and avoid deep thinking about side effects and consequences, and avoid meetings and discussions by making guesses. After all, it has to go through testing anyway and they'll send back any code that doesn't really work (well enough).

There isn't time to spend on this feature, so she should not bother with refactoring and test-driving and pairing or reviewing. Those things feel like "taking time for quality" and she is being rewarded (reputation-wise at least) for turning things around quickly; emptying her plate.

A tester will probably have to decide which tests he will not run this time, so that he can move forward quickly. Perhaps he can downgrade the severity of some bugs. Returning it to the developer will get it off his plate fastest, and is safer because testers tend to be blamed for every defect not caught.

Of course, there may be bug teams.  My "true story" above describes how that works.

Let's not get into operations. There is no place that plate-emptying stress is higher, and tolerance for errors is lower. You've got to love ops people, because everything is an emergency and nothing is appreciated, and they still show up. In fact, they show up at insane hours and weekends and holidays and such. They miss the kids' little league games and family birthdays. They work Christmas eve. Give your operations team some love; do something to make their job easier.

Customer support is held to tight schedules. How can they empty their plate faster? What if they pass a client off to some other representative? What if they just give some stock advice and abandon the user? What if they just recommend "reboot and call back"?  We have all seen instances of tech support people held to a standard of "45 seconds per call" so that they empty the queue rather than serving the customers.

Managers have to deal with plate emptying, too. They have to manage people less and shuffle lists and calendars more in order to keep up with the activity, all the while pushing to increase that very burden. Sometimes people-centric mentors who make it up the ranks are stuck being "meeting denizens" instead of really managing projects and people the way they always wanted to.

Most everyone came to the industry intending to do good work well and proudly. But organizations that value plate-emptying and busyness can destroy pride in workmanship by demanding brute-force solutions and intense activity from employees while ignoring larger system problems (such as the turbulent work flows and deferring learning) which actually prevent building and shipping working software.

What About Agile?

When agile goes well, it makes good workmanship (craftsmanship) and good decision-making possible.  It reduces stress and rework for everyone involved, and has a greater solidarity across roles due to the use of cross-functional teams.

Ideally, agile methods make it possible for teams to work at a sustainable pace, and focus on value rather than quantity. There is focus on economy of scope rather than economy of scale.

In particular, modern agile is built on safety, continuous definition and delivery of value, and continuous learning. Perhaps this is the way it was always supposed to be.

BUT, what we tend to see in many organizations is a fascination with velocity.  When teams have pressure to not only take on the maximum workload but also to complete it within a too-short fixed period, they become exhausted and frustrated, and are driven to obsessive plate-emptying behaviors.

This is all about the stress-performance curve at that point. Developers are stressed and exhausted past the point where they have good cognitive function, and plate-emptying is all that is really left for them.

Isn't That A Good Thing?

Yes, I realize that "the perfect is the enemy of the good" and that people really don't have time for infinite gold-plating and "cadillac" answers. Who can afford perfect code?

But no legitimate business can survive, having adopted "quick and dirty" as its standard of excellence.

Adding sufficient design and reasonable automated tests, software is transformed until most changes become reasonably easy and quickly-performed. Not all changes become "easy" but they become easier than they would be had the code been allowed to decline into a comical and tragic mess.

Many times plate-emptying delays release of useful software by weeks or months.

Often focusing on "minimal touch time" results in disasters and loss of staff, and sometimes in stress-related illnesses and panic attacks up to six months later.

Despite what you might read sometimes, being a software developer in some companies is disturbingly stressful.

I suspect the reasons behind poor craftsmanship, poor support, poor service largely stems from rewarding the practice of plate-emptying

Should We Bust Those Lazy Plate-Emptiers?

Blaming and shaming is generally useless. In this case it is also unfair. It is wrong to demand people do a thing, reward them for it, and then blame them for not resisting the system and refusing the rewards.

When I toured around the US with the "perfect day" exercise, I found that knowledge workers are almost never slackers. Their ambition, almost universally is to take on a problem that is hard (for them) and to work it to completion. A perfect day isn't "goofing off and playing video games at work" for them. It's doing good work and being respected for it.

So what's with the plate-emptying? What does it mean?

People are doing what they are doing because the system demands it and because they are too fatigued to fight it.

If you don't want people to abandon work for others to deal with, you have to give them enough time to work something to completion instead of racing through it to "get it off their plate."  In doing the work, they must be encouraged to find ways to make doing a complete job better, faster, and more consistent. There isn't always such a way, but help people build habits that take a lot of stress and decision-making out of the equation.

It is hard for some to believe, but if you want next month's work to be faster, you have to spend a bit of this month improving the code that the developers will start with next month.

Deming said long ago that all anyone wants is to take pride in their work. We need work systems that respect the human limits of the people who do the work, and we must not solve intellectual problems with brute force (more hours, more people, more typing).

Alternatively, most programmers I know have had a job in the past where pressure and plate-emptying were common practice, and sometimes these practices are carried into new job situations where plate-emptying behaviors are unnecessary and unwanted.

It's good to reflect on where you are, and what is most important to your customers.

Wednesday, November 11, 2015

What is "enterprise"

Gathered answers: 

  1. A for-profit concern.
  2. Involving strangers (you can't know and care about 5000 people individually)
  3. Using low-cost "resources"
  4. Involving huge budgets
  5. Pyramiding
  6. Multisite, with considerable offshore work
  7. Having a long-entrenched industrial-age culture
  8. Using fungible "resources" so staffing can be "re-balanced" easily
  9. Having strong central control (seeming necessary when working with strangers?)
  10. Having many teams contributing parts which share an architecture
  11. Having many interdependent projects, with independent teams
  12. Having a strong identity/culture ("unchangeable self" fallacy)
  13. Having promises outstanding in the form of multiyear "roadmaps" 
  14. Essentially waterfall view of software 
  15. Law of 2nd floor -- nobody 2 levels above or below you knows what you really do for a living.
  16. Essentially addicted to using brute force (large numbers) to solve problems.
  17. Having complicated budgeting processes with slow multi-approval acquisition cycles.
What is your answer about what "enterprise" means or implies?

See Also: Principles of Large Organizations

This was discussed on Agile For Humans.

Friday, October 16, 2015

Dot-Programming your Object Oriented Code

I was once told to "exalt the obvious."

There is a power in it, because sometimes we overlook obvious things that are blessings to us and can reshape our world. This, I think, is one such.

'Way back in the 80s and 90s we were trying to get people to practice Object-Oriented Design and Object-Oriented Languages were gaining a bit of ground. Heck, in '86 or so C++ started to be a big deal, because it mixed some OO with our beloved C. Soon we saw semi-OO BASIC and even a version of Object-Oriented COBOL. Wow.

We tried to codify principles and practices that helped people to do good design. You probably followed all the great stuff we did at Object Mentor, led by Uncle Bob Martin (who I still appreciate and respect, though we don't see each other very often).

We expounded on coupling and cohesion, as well we should, but we lacked the mechanism in our programming environments to help us really seat the idea of OO in the minds of our fellows.


Well, in the meantime, the IDE manufacturers (and plugin writers, God bless them) created something that solves 1/2 of the problem. They created smart code completion.

Yes, it was a long time ago. And yes,  it's everywhere, from IntelliJ and Eclipse to Pycharm and Idle, from Vim's to Emacs. Nothing new in the mechanism here.

Heck, most of us wouldn't want to consider using an editor that couldn't give us some kind of smart completion. It would be like working in edlin.

And, dolts that we are, we said "oh, that's kind of nice" and we went about our business as usual, and didn't react to the amazing manna from heaven that this innovation represents.

We snatched defeat from the jaws of victory!

What were we thinking?

See, what this really gives us is..... ....

So, basically, you type the name of a thing and then a dot, and you're given a list of actions that the thing can perform.

Big deal, you're still saying?

Okay. Let me slow this down for you.

When you write a program, you will not read the documentation. You don't have time and inclination for that.

You don't memorize the class hierarchy or the class interface. There are far too many classes and you are far too smart and mobile and frankly short on time to spend a bunch of time memorizing stuff. You are no fool.

You won't read all the code. Nobody reads all the code. The days when you wanted to write long methods so that people can read them from top-to-bottom are over. That's dead. Dead like .bat scripts and CP/M. It's over.

So now, you're working in a class and you type the name of some object and you press the dot. The list that pops up is your guide to the world of the object whose name lives on the left side of the dot you just pressed.

And you know everyone else is doing the same thing.


When you write a method that does anything remotely interesting, you have one VERY important question to answer:

When someone needs this method, where will they look for it?

Or, slightly rephrased:
What object should be on the left of the dot? 

Let's say the object is a "Playlist." Don't worry about what that means, just stay with me here. And assume you're writing a report to say which playlists are used by which accounts in the system, and how long each one is. Just imagine that's valuable.

Failure Is Always An Option

You could, of course, write a method that takes a Playlist object and returns the number of items contained in the playlist. That's useful. Before you really understood the universality of DOT PROGRAMMING you might have written it as a local function to avoid "mucking with the design."

But now you're enlightened.

Now you realize that most people who need a playlist's length probably won't go looking for it in your crummy little report class out in the jerkwater corners of the application.

Their cool new code should have nothing to do with your report class. This is especially true if their code is in the UI or Web Page or deep in the business logic.

Your current code will not be the object on the left of that dot.

You can leave it where it is, but that doesn't sound like such a great idea now.

Cohesion: The Single Responsibility Purpose

Where did you look for the length function? Why, you looked for it as a method on the Playlist.

When you saw it didn't exist, you wrote your method into the report.

It would have saved you time if the method already existed on the class where it operates.

And then it hits you. When the next programmer doesn't see it pop up as a choice on the Playlist object, they're going to write it too. And the next one. And the next.

Everyone will duplicate this method unless they find it in the one place that it really belongs (ie that it is expected) in the code base.

And they might mess it up. And then you're going to think your method is at fault and go debugging in the wrong place, possibly. That's going to suck.

This waste will continue until someone decides to move the method to someplace where their coworkers can find it ... and then they'll have to find and delete all the duplicates that have popped up or else there will be bloat everywhere.

Oh, no. There probably already is.

Feature Envy

But the method is all about the Playlist, and only touches methods and variables of the Playlist. It really has almost nothing to do with your report. It's in the wrong place.

And sure enough, it's in four or five other places.


So you resolve to move the method to the only reasonable place where it won't cause duplication and frustration and wasted effort -- to the Playlist class.

And you'll get rid of the duplicates.


But if you're going to put it on the Playlist class where everyone is going to be able to call it, then it had darned well better work. You don't want to be the fault of future failures.

So you pick the best (most comprehensive or performant) of the existing methods. Maybe we combine the strengths of two or more of those methods together.

Then we methodically replace the calls to some local getPlaylistLength and getPlayListSize and countOfItemsInPlaylist with Playlist.getLength(). So far everything seems  to still work.

So I guess we'd better write some automated tests that put this thing through its paces and are wise to its subtleties, like recursive containment and non-unique contents, and .... wait, are we using the right data structure for this?

Now we've got testing (though it's post-facto) and design thinking, because if we put it in the right place, then its quality matters.

Embrace Dot Programming

An object-oriented system is really a system organized like a big filing cabinet. Things (data, methods) are located where you expect them to be.

Dot Programming is just Object Oriented Programming, if we decide to listen to what our code is telling us about the social context of our work.

Thursday, October 15, 2015

What To Read

There was an opportunity at a recent open space conference for Mike Rizzi and myself to conduct a short session on "what to read."

As expected, there is more here than anyone could hope to digest in a year of hard reading, but I think this might be interesting to the Agile Otter audience, and I hate to waste all the good work Mike did in organizing and fact-checking the titles.

Here is Mike's note from the conference proceedings: 

In this session, everyone wrote on large index cards titles of books that have inspired them. They were then arranged them on the floor looking for patterns and affinities. We then took turns saying why each book inspired or helped us. The fast paced discussions were fascinating, and I left with even more books to add to my reading pile(s).   -- mike rizzi


  • Symposium and Phaedrus - Plato
  • Liftoff: Launching Agile Teams & Projects - Diane Larsen & Ainsley Nies
  • Impro: Improvisation and the Theatre - Keith Johnstone
  • Antifragile: Things That Gain from Disorder - Nassim Nicholas Taleb (On Tim's list)

  • Artful Making: What Managers Need to Know About How Artists Work - Robert Austin and Lee Devin
  • Esther Derby blog - - (Tim's frequent visit)
  • Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - Tom DeMarco - (Tim owns but hasn't completed)
  • Pair Programming Illuminated - Laurie Williams & Robert Kessler - (One of Tim's favorites)
  • Being Wrong: Adventures in the Margin of Error - Kathryn Schulz

  • The Leader's Handbook: Making Things Happen, Getting Things Done - by Peter Scholtes - (recommended for alternatives to "traditional" management and employee assessment).
  • Behind Closed Doors: Secrets of Great Management - Johnna Rothman & Esther Derby
  • The Barbarian Way: Unleash the Untamed Faith Within - Erwin Raphael McManus (warning: christian content) (Tim recommends for what it teaches about courage).
  • The Mindful Brain: Reflection and Attunement in the Cultivation of Well-Being – Daniel J. Siegel M.D. (Interesting for teaching about choosing curiosity over judgment)
  • Peopleware: Productive Projects and Teams (3rd Edition) - Tom DeMarco & Timothy Lister

  • Thinking, Fast and Slow - Daniel Kahnneman
  • Facilitator's Guide to Participatory Decision Making - Sam Kaner
  • The Honest Truth About Dishonesty - Dan Ariely - ("Permission to be human" -- this describes how people behave wrt honesty or cheating, and so allows us to understand how our fellow man operates as well).

NOT PUT IN AN AFFINITY GROUP - (Both brilliant works on human behavior and how to operate your own brain-- helpful for leading teams).
  • Drive: The Surprising Truth About What Motivates Us - Daniel Pink
  • Your Brain at Work - David Rock

  • Lean UX - Jeff Gothelf
  • Working Effectively with Legacy Code - Michael Feathers - (A classic!)
  • Nature of Software Development - Ron Jeffreis
  • The Craft of Research - Wayne Booth and Gregory Colomb
  • Essential Scrum - Ken Rubin

  • Kanban: Successful Evolutionary Change for Your Technology Business - David J. Anderson & Donald G Reinertsen
  • Manage It!: Your Guide to Modern, Pragmatic Project Management - Johanna Rothman
  • The Seven Habits of Highly Effective People - Stephen Covey - The classic! Tim prefers "first things first" of the two habits books by Covey.
  • The Scrumban [R]evolution - Ajay Reddy
  • Hyper-Productive Knowledge Work Performance - Steve Tendon & Wolfram Müller
  • Principles of Product Development Flow - Donald G. Reinertsen (card note: Eye opening)

  • The Fifth Discipline: The Art & Practice of The Learning Organization - Peter M. Senge
  • How to Make Sense of any Mess - Abby Covert
  • A First Look at Communication Theory - Em Griffin

  • Made to Stick: Why Some Ideas Survive and Others Die - Chip Heath & Dan Heath
  • Decisive: How to Make Better Choices in Life and Work - Chip Heath & Dan Heath
  • Switch: How to Change Things When Change Is Hard Hard - by Chip and Dan Heath
  • Agile Estimating and Planning - Mike Cohn 6 (card note: life changing)
  • Extreme Programming Explained: Embrace Change (1st Ed.) - Kent Beck - awesome.
  • The Art of Thought - Graham Wallas- (an influential work on how to cultivate or improve the quality of thinking)
  • Out of the Crisis - W. Edwards Deming - (A seriously counter-cultural classic book on how to change the industrial environment to be more effective, which includes being more humane and understanding systems)
  • The Scrum Guide - Schwaber & co. - 
  • Mary Poppendieck and Tom Poppendieck books - ALL of them
  • Psychology of Computer Programming - Gerald M. Weinberg - (another classic that examined the work of people who are thinking technically for a living!)
  • Perfect Software and other illusions about testing - Gerald M. Weinberg
  • Are Your Lights On?: How to Figure Out What the Problem Really Is - Donald C. Gause & Gerald M. Weinberg (Tim's favorite human-centered problem-solving book).
  • Reinventing Organizations - Frederic Laloux
  • Turn the Ship Around!: A True Story of Turning Followers into Leaders - L. David Marquet w/ Stephen R. Covey (Foreword)

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" (not really a law, more of an observation) of the second floor builds on Dunbar's Number by stating that "generally, no person 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 great, which puts the grand-boss into a different tribe. The grand-boss and the front-line team deal with different problems, and are all too busy to develop a deep understanding of each other.

In the "trenches" where all the various kinds of developers work, management tends to be a remote "them" who are disconnected from the nature of the daily work. Their primary concern seems to be increasing workload and cutting costs. Policies seem arbitrary and fashion-driven, or else driven by political self-interest.

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. There is a strong and growing suspicion that they are stealing money by wasting time and supplies (further reinforced by slipped estimate-driven schedules).

This isn't by choice, but is a problem of scale and social distance. After all, those remote persons 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/or 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.