Wednesday, February 3, 2016

Naming good is what Position?

I want to drop in a quick note about variable and class naming, one of my favorite hobby horses.

I talked a little bit about choosing more completable names already. I think that is very important, and you would be well-served by paying attention to that bit.

Today let's consider the serial position effect.

In any programming namespace, we're going to come across some naming issues. Here is a non-comprehensive, non-exclusive list:

  • Objects with a common base will want to include the base class name in the derived class, leaving us with MonoNUnitTestRunner derived from NUnitTestRunner derived from TestRunner, possibly breaking naming in its derivation from CodeEvaluationRunner and on and on.
  • Objects in languages with declared interfaces have a tendency to want to declare the interfaces in their names. An iUserAction will have a UserActionImpl in many cases, whose children may follow the prior rule above. 
  • People love naming the patterns they use in implementing an interface. You will see names like UserActionVisitorFactory 
  • Noise words will creep in, so that you may have a Subscriber class with a base class tied to persistence. You can't call them both Subscriber unless you split them into separate namespaces, so you'll tend to name one SubscriberInfo or SubscriberDataObject or the like. Not to mention SubscriberObject and SubscriberManager and BaseSubscriber. Of course "manager", and "info" and "data" and "object" are completely noise words in an OO system, but they sure are prevalent. 
  • Fuzziness and generality will be signaled by the use of vague terms. Identifier is general, FactoryManager is general, pattern-related (possibly) and vague.  Often when we don't have a clear, unique purpose for an object, we'll use vague terms.  It might be a code smell. It means that other, similar terms will have to carry "warts" or "qualifications" to be unique. Maybe there must be a UniqueShortStringId so that we don't confuse it with the UUID or GUID we use in Id. 
  • People suspicious of the 'magic' of namespaces may feel uncomfortable with letting the namespaces and class names be sorted out by the compiler (for some reason) and may embed namespaces and class names in their object and method names. I know, it's redundant and seems silly, but it happens. We end up with CustomerManagement.Customer.getCustomerName(). Sigh.
Is it wrong to have compound names? Probably not, and besides "wrong" is an uninteresting qualifier. Maybe better questions will help:
  • Is it helpful? 
  • s it only a coping mechanism for over-used namespaces? 
  • Is it a signal that our code is degrading? 
  • Is it a sign that we're doing a good job? 
  • Is it a temporary state, that might be leading us toward more manageable code? 

Rather than answer ethical questions that we don't have room for in this space, let's consider instead that we have compound names, for better or worse.

What ordering should we use?

Serial position effect tells us that we will recall the first and last parts of the name most clearly. This has been illustrated in even smaller scale by silly facebook posts like this:
"If you can raed tihs, tehn you hvae a vrey rrae gfit. Olny sveen penecrt of plpoe are albe to usdtnernad tihs txet. You hvae an azimang bairn!"
Which of course, contains misinformation because just about anyone can read it if they look at it for a few seconds and can read English at all.

The interesting bit though, is that it is true that you don't really struggle that much when the middles are scrambled because your brain doesn't really latch onto the middles.

Maybe this is why it's easier reading these really short paragraphs than the long ones above and the short bullet points instead of the longer ones.

It seems that if we are going to use long compound names, we might be better off if we:

  • Put the most important word at the front to support dot-programming.
  • Put the next most important word at the end of the name, so it's memorable and recognizable.
  • Either delete the other parts because they're noise, or bury them in the middle.
Give it a shot today when you're programming. It might lead you to more clear and easily-read names!



Wednesday, December 9, 2015

The Productivity Formula

Productivity is clearly some kind of ratio; it is some kind of N:M relationship, but it's hard to know quite what the N and M are.

Of all the poor ways one may define Productivity for software developers, there are some really horrible formulae including "lines of code per developer" and "story points per iteration", measures which really measure all the wrong things and which might send Charles Goodhart into a tizzy.


Rather than rant more on those, let's cut to the chase and give the definition that most people really use:


(what you did)

----------------------------

(what I wanted)


You see, management is really not a data science. It is generally practiced as a semi-educated gut feel, because most managers in software organizations are really programmers risen through the ranks. Maybe 1/3 of them have studied computer science (judging by the popularly quoted folk-statistic that 30% of people work in the area of their college major).  Most of them have learned to manage in a sink-or-swim way, or possibly mentored in a "tribal knowledge" kind of way.

As a result, most decisions are based on trust and gut feel. 

This measure is a gut-feel relation. As a gut-feel relation, we really should adjust it to say "what I think you did" on top, but I'm leaving it as-is. 

The thing that might confuse some readers is that this is not a snarky rant. I believe that this relation is not only "true" but possibly "correct" for all of the subjectivity that is inherent.

Whether it is right or not, it seems to be true, and gives us some leverage and predictive power. In other words, however imperfect and undesirable you may think it, this is a workable definition.

I have long talked about the "trust transaction" where we give transparency and delivery, and in return are given trust (generally in the form of lessened governance and increased autonomy).  Notice how this addresses the relationship.

I am not the first, nor even the brightest, to have talked about "expectations management" and "business and development working together" which improves the relation by "truing up" both entities.

Nor am I the first nor brightest to discuss the idea of delivering earlier and oftener. Notice that this helps to calibrate not only expectations but also observations.

And finally, note how not having anything to show for your past N days worth of effort affects the relation.

I offer it here for your comment, acceptance, absolute rejection, or ridicule -- as you wish.

Friday, November 13, 2015

Plate-Emptying



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.


Charlie developed a technique for getting the veggies off of his plate.


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.

And, thanks to Singh's Inevitable Avoidance, companies whose developers, testers, customer service, and operations have been playing "hot potato" with defects for months or years have developed much more efficient ways of playing hot potato, and have even come up with metrics to show how efficiently they are improving the speed of hand-offs.

Often focusing on "minimal touch time" creates unproductive (even counter-productive) pressures, which in turn result in release disasters, interpersonal conflict, and loss of staff.

Despite what you might read sometimes, being a software developer in some companies is disturbingly stressful to the point of causing stress-related illnesses and panic attacks up to six months later.

I suspect (and observe) that the reason behind poor craftsmanship, poor support, and poor service is often pressure for individual plate-emptying rather cooperative completion of tasks. This pressure often results in practices like "rank-and-yank" (AKA "hunger games") where staff are retained or released based on speed of "productivity" measured in speed 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.

Serendipity

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..... ....
DOT PROGRAMMING


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.

THEREFORE:

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.

Refactoring

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.

Quality

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

Enjoy.

PHILOSOPHIC BASIS
  • 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)


LEADING CREATIVITY
  • Artful Making: What Managers Need to Know About How Artists Work - Robert Austin and Lee Devin
  • Esther Derby blog - www.estherderby.com/category/insights - (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


LEADERSHIP
  • 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


BETTER DECISION MAKING
  • 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


CRAFT
  • 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
  • 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)


SYSTEMS THINKING
  • 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


NOT DISCUSSED BUT NOTED
  • 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. - http://scrumguides.org/ 
  • 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 (tottinge@gmail.com or tottinge@industriallogic.com) 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.