Monday, August 18, 2014

Being the Remote Programmer - A Reflection

Being remote is a bit of a compromise. This is not my first time to reflect on the issues, but this one might be helpful and the topic stays fresh for me. 

As a full-time remote I suffered through many issues, including:
  • bad conference calling systems
  • frequent drops
  • bad phone service sometimes
  • iffy internet and screen sharing 
  • switching from broadband to cell phone for internet connectivity
  • ISP downtimes
  • lag (omg lag!)
  • time zones (we were in India, Illinois, Colorado, Oregon, Utah, and Iowa. My current company is in Amsterdam, Brazil, East Coast, Midwest, Texas, West Coast -- and we have satellites & customers in India, UK, Russia, UAE, New Zealand, and China among others)
  • unavailability when people were in emergency meetings onsite that I didn't know about
  • being outside of the social conversations
  • being unaware of the mood at the office
  • missing gossip that everyone else took for granted
  • other people not seeing/appreciating what life was like on my end
  • events at home taking me out of work context (if only mentally, or momentarily)
  • raccoons eating my internet cable (and part of my roof)
  • storms knocking out my access to the office

But I was happy to be a remote, and to pair with teammates remotely, and to have a little more control over my environment, and I accepted the bad with the good. It had advantages. 

People wanted to work with me, and were willing to go through the hassles so we could work together.

We looked for every Pareto change, where conditions improve for at least one person and are not made worse for anyone else.

If we made everyone else work as if they were remote too, we would have forced everyone on our system to the lowest common denominator -- which would have resulted in less work being done (and completing less often). We didn't do that.

We don't make being remote any worse than it had to be, and we also took advantage of being present to the greatest extent we could. We even had remotes come to work at the office from time to time at company expense so we could gel as a team and see each others' faces. The rest of the time, they would either photograph the board, or read it to me.

Ultimately, it's about getting work done more often (even if not "more quickly") and working together as a team. 


Local team members will learn to take care of the remote tribe-members. 

At least, that is my experience. 

Your Mileage May Vary.

Thursday, August 7, 2014

The Good Guilt Trip

Take a trip with me for a minute.


Imagine that today you decided to shoplift. 

If you are like me, that thought makes you edgy and nervous. If you are not like me, you can consider it with no feeling of discomfort at all. If you are a regular shoplifter, it might even give you a bit of a thrill.

It makes me feel bad. Why?

My great-nephew lived with me for a while. He believed that if he felt bad, it was incumbent upon everyone else to placate him. He would stage elaborate tantrums, public meltdowns, and crying fits. Creating feelings of guilt or shame in others was his reliable strategy. He was nine years old and never had to do anything he didn't want to do, or eat anything he didn't want to eat (at 9, he had never eaten a sandwich, soup, or vegetable until the 9 months he lived with us).

Certainly, the kind of guilt that my relative used was a self-serving, manipulative, control strategy. It's not uncommon. I have known adults well into their sixties who were still trying to appease the voices of their decades-long-past parents who used guilt and shame to condition them.

It's a sad when guilt is abused but it is so fundamental and so easily leveraged that guilt must have some primal, legitimate use. If we all have it, and have a lot of it, then the ability to feel guilt must bestow some evolutionary advantage.

Why does it work?
Why are we so prone to accept guilt and to act on it?
Why do I feel bad if I merely consider doing something unfair or unkind?

Diana Larsen talked at Agile2014 about "taking care of your tribe" and this resonated with a lot of people. "My tribe" became the catchphrase used in conversations the rest of the week.  As social animals, we form connections and "tribes." We have a drive to preserve and deepen our relationships.

I find that my guilt feelings are indeed social. They warn or remind me of a risk of not living up to an agreement or expectation. It is clearly relationship-based.  I want to "take care of my tribe." I don't risk hurting my tribe-mates.

Javan Lutung
Social Animals
I think that feelings of guilt or of possible guilt are self-protective and socially responsible. When I consider taking unfair advantage or hurting someone else's reputation, the feelings I get warn me that I am at the edge of betraying a trust.  I like that warning. There have been times that it caused me to think about my actions and consider a more appropriate and fair action.

If the feelings are really a social "spider sense" that warns us of betrayal to our tribe, then they are good feelings to be cultivated and honed. They are not to be avoided or remedied, but to be trained and leveraged by us.

Merely choosing to "not feel bad" by refusing all guilty feelings leaves my decision-making apparatus with a social handicap as indeed it has done with my young relative, who refused feelings of guilt without becoming socially responsible and "fair."

These feelings also must be inspected, lest they become an easy control mechanism for a manipulative other.

I started to inspect my own guilt feelings with curiosity and openness and to take a more clinical view of them. I've been deepening a few understandings:

  • Inflicted social guilt is manipulative, often used to gain an advantage. It can be rejected.
  • The sense of guilt can be over-sensitive; betrayal can be felt only on the side of the oversensitive person.
  • The social guilt is sometimes imaginary; the "others" we fear disappointing do not have the expectations we think they have for our behavior..
  • The social guilt is sometimes real and reliable. As long as it is in "future tense" it's easy to work around fairly. Even in past tense, there are ways to remedy guilt and move forward.
  • Some actions really are a betrayal of trust, and I can usually "just say no." When there is a fact of betrayal, feelings of betrayal are perfectly valid. 
  • If you realize it is a social sense, you can learn to forgive as you are forgiven. It is not a permanent shame.

If these feelings are a good and useful adaptation to living socially,  I'm interested in information that will adjust or inform my opinion about this sense of social responsibility and how to grow and use it ever more responsibly and socially.



I am not a psychologist. I'm just trying to work through this stuff.

I don't know if this is universally true, I only know that it is working for me (so far).



Wednesday, June 11, 2014

Process Improvement Principles

This is not a manifesto.

It looks a lot like a rather famous manifesto (the middle of it anyway) but it is not a manifesto.

This is just a set of principles that I've successfully applied in numerous personal and professional settings, always with good effect.



Pull is a better flow than Push
Continuous is more competent than Batch
Agreements are more negotiable than Orders
Brains per Task is more efficient than Tasks per Person
Improvement is a better goal than Compliance
Fail Now is cheaper than Fail Later
Simplicity works better than Discipline
Safety is best

May they serve you as well as they have served me so far.

Peace.

Wednesday, May 28, 2014

Defending Scrum Against Stupid Arguments

I'm not a big scrum promoter, but I am VERY familiar with scrum and have coached many teams and always been able to improve their success with the method to some extent. I've taught scrum, and even have written a book about scrum mastering. I don't have to love scrum (not more than XP for certain!) to see that it's getting a bad rap.

Ignoring advice to "never blog angry" I'm going to let the grumpy old man out for a minute, in hopes you'll hear what he has to say. 

Suggestion:  Before railing on how scrum doesn't work  you should be sure that what you're doing is scrum.

Some people say they're doing scrum because they have planning meetings, morning status meetings, and sometimes have reviews or retrospectives. But they're not sure why they're doing them, and these meetings just take time away from what would otherwise be potentially productive programming and testing time.

So, let's get back to the basics here.

Scrum is entirely based on
transparency, inspection, and adaptation.

That might not sound right. You might want some citations to back up what I'm saying, because it's very likely that you weren't given this talk when you started scrum.

See here:

Okay, three pillars. We get that, right?





Those pillars are not "planning meeting, standup meeting, retrospective."

They are (repeat with me) Transparency, Inspection, and Adaptation. 

But if you say you are doing scrum, and you aren't getting what you want out of it and you're not looking at your process and adapting your practices to get what you want... well, then, you are not doing scrum.

Nor is it XP, or AUP or Crystal or DAD or FDD or Lean or Kanban. 

If you fail and you aren't using Transparency, Inspection, and Adaptation then what you're doing isn't a scrum failure. It's a failure to use even the most fundamental and essential features of scrum.

If you've only sort-of almost tried parts of scrum (like the meetings), and have tried no other agile method, then you can't say "agile doesn't work" because your experience is limited to not really trying a single agile method.

Sadly, that is the core of most of the arguments I hear: "I didn't really try scrum, and it didn't work for me. Therefore all agile methods are fundamentally worthless."

Guide to argument:
  • If you want to hate on scrum, then go ahead. Get to know it, and give us the real dope on why it doesn't work for you.
  • If you want to hate on XP, go do it for a while and then shout your grievances to the rooftops.
  • If you want to hate on agile, the learn several agile methods and show us how following them all lead to likely failure.
  • Heck, go do some research and then report on project that use some methods or parts of methods and fail; how and why it happened. That would be mighty useful.
  • If you just don't want to learn or do any of them, that's okay too.  You can honestly argue "that doesn't make sense" or "I don't like it" or "I'm happy as I am." You are big enough say it, and we're big enough to hear it.
I'm okay with all of that.

All valid, informed arguments are welcome. I don't have a sacred cow or beloved method that I'm unwilling to part with. I'm an Anzeneer, not someone whose paycheck is tied up in scrum or agile promotion.

I'm just tired of arguments of the form "your whole family is unreliable, and I know because I once almost asked one of your cousins about it."

We can do better than that.

Any REAL argument will find open ears and a willingness to inspect and adapt.