Just ignore this post, I just need to release some steam...

We just had an emergency team meeting.  The topic: it's been noticed by the executives that we're not always around when they are.  Someone needed something and one of us wasn't there to oblige.  That must have really chapped their hide.  

Well, I've noticed some things too.  Here's what I've noticed:

• I'm VPN'ed into work at midnight fixing the build someone else broke;
• I'm constantly tweaking our unit tests to keep them working as the rest of the team gets to plod on to greenfield pastures;
• I'm responding to support emails at 2am;
• I'm answering the support phone at 4am;
• I still make the 9:30am scrum;
• I bust my hump as a principal developer on a project, only to hear the executives single-out my superiors to praise for my work;
• After four rounds of layoffs, I've taken on so many roles here I've lost track;
• I haven't dropped the ball on any of my responsibilities (or if I have, no one has let me know about it);
• I've been willing to drop my life for days at a stretch to make emergency trips to fix client issues;
• I'm frequently the last one out the door at the end of the day;
  
• I see my kids for maybe 90 minutes a day;

... and more thing I noticed: the people I work for only notice me when I'm not around.

Another fear I'm seeing on the team is a fear of changing existing code.  The fear may stem from several sources: the code implements complex behavior that is undocumented; the code is inherited from a resident expert who is retasked or otherwise unavailable; the code hasn't been maintained properly and reads like a plate of spaghetti.  Whatever the source, a team member's response to the fear follows the pattern:

When team members are afraid, they will act in either their own interest of self-preservation, or in the interest of team survival.

When confronted with such code, a team member can choose one of two paths: they will choose to do as little with the code as possible, leave it alone as much as they can and still satisfy everyone's expectations; or they own up to the situation and remove the source of the fear, making the code easier for anyone to cope with and understand.

Those who pursue self-preservation take the former track.  They exert a lot of effort to develop an understanding of the code, but don't do anything to persist or share that knowledge.  Chances are they are trying to act in the team's interest by developing specialized knowledge of the code, but in the long-term they benefit only themselves.  The code remains an untenable briar patch for the next poor sod who receives it.

Those who pursue the best interests of the team take the latter approach.  They write unit tests around the existing code; they refactor the code and leverage the common design patterns to make the code comprehensible; they seek clarification from the business heads and write documentation targeted to other developers.  Their actions are targeted, whether implicitly or explicitly, at communicating with the other members of their team.

I've recently taken on the role of Scrum Master at the office, something I agreed to do in order to try out some new tools and techniques such as user stories and planning poker.  Making the switch from engineering software to engineering team results has been enlightening.  Keeping the pigs productive and the chickens out of the sausage factory has been exhausting.  This is due in no small part to sudden layoffs and subsequent attrition that directly impacted the teams. 

Four weeks as Scrum Master in this environment has reactivated my dormant psychology degrees.  Anyone exposed to psychology knows that fear is the fuel for a lot of animal behavior (e.g., two of the the four basic "F's": fighting, fleeing, feeding, and reproduction).  Some animals act independently to ensure their own safety; others act selflessly to ensure group survival.  Team members fall in line accordingly:

When team members are afraid, they will act in either their own interest of self-preservation, or in the interest of team survival.

I'm making no value judgments here - I would never fault anyone for doing what they feel is necessary to protect themselves and their family.  This is merely observation. 

Let us consider the fear shared across the team: losing their job.  Some act to ensure their own survival: they leave the team for a more stable environment; they hoard tasks to protect their value to the company by having a lot to do; etc.  Others act to the benefit of the group: they seek out improvements to the team processes to help compensate for loss of resources, they maintain their value to the company by moving into vacant but necessary roles; etc.

The longer I'm in the Scrum Master role, I can see the axiom apply to more and more individual behaviors.  Fears will vary, responses too; but the pattern tends to hold true.

Next time: Coping with the Fear of Changing Code