My Role Model

Anpanman by Takashi Yanase

I’m half-Japanese but my wife introduced me to Anpanman by Takashi (嵩) Yanase (柳瀬).

I can’t give any better description than the Japanese Media Communication website:

“Anpanman will go anywhere to help anyone in trouble, to drive away villains, and to save people from starvation by allowing them to eat his face.”

“What? Let his face be eaten? No need to worry. His face is made with sweet anpan (bread filled with bean jam), hence the name Anpanman.”

“Anpanman’s very life depends on allowing others to eat, and once eaten, Anpanman can restore himself endlessly.”

“He does not look handsome or strong, but he never fears any adventure and is continuously flying to aid the hungry people and the children with difficulties.”

“Anpanman is the hero of the new age, glowing with friendship, endeavor and justice.”

I’m a Sideways Agilist

I’ve posted about why I need to encourage agile practices outside my department.

Fiddler Crab by denn

If Scrum is isolated within one team, its very success can be used to counter further adoption. “Agile works for you but what we do is different. You do X we do Y.”

This resistance is a direct result of what Andy Hargreaves calls balkanization — groups insulated from each other, with hard boundaries, loyalties and a political complexion.

Creating a culture where groups work together to improve the organization is core to lean and agile. So the best ways to counter balkanization are the very principles under challenge.

I’m tackling this top-down by lobbying senior executives to bring in an agile/lean coach, bottom-up by removing impediments for my team, and, perhaps most significantly, sideways by initiating a Scrum in another department.

I have tentative approval from another department’s senior managers. Now, I have to meet with line managers and identify a backlog of work. Then solicit volunteers for a team.

I’ve taken Ken Schwaber‘s words to heart and asked them to Scrum their hardest challenge or the work they think least suited to agile.

So many things can go wrong. Of course, nothing that isn’t already going wrong. That’s the point.

Scrum will highlight those problems and make solving them obvious and necessary if no easier.

More to come…

LinkedIn and Age

Astronomical Clock

My company recently held HR training for managers where the instructor said:

  • Do not require dates of employment on applications
  • Do not note or refer to dates on someone’s resume or application

All this because considering age when hiring is, in most cases, both wrong and illegal.

  • If I list three jobs, each of which I worked four years, am I over 40?
  • Same jobs with dates. I began the first job in 1992, am I over 40?

I thought I’d ask LinkedIn why they require the display of dates.

This is their reply…

From: LinkedIn Customer Service
Sent: Monday, August 13, 2007
To: Ken H. Judy
Subject: Re: dates worked in experience profile

Hi Ken,

While we can understand your position along with your companies HR training basically providing the length of employment or the dates you began with a company (start date) and the date you left the company (end date) would pretty much be the same. If I started with LinkedIn March 01, 2007 and I left them April 1, 2007 that would mean I was one month old? I don’t believe this would really have much to do with a person’s age. When entering employment dates on a resume you don’t enter your date of birth neither should you do that on your CV. Please let me know if this addresses your concern as I am not sure I understand how entering your employment dates is age based discrimination.

Thanks

I’m comforted that you “understand my position”. Thanks LinkedIn Privacy Lead!

I realize experts recommend listing dates and only using the most recent 10-15 years of experience. Still, what I reveal about myself is fundamentally my decision not the administrators of a social network.

Oh, and thanks for clearing up that thing about the one month olds. I was confused about that one…

Dysfunction in a Word

Handoff
Creative problem solving as rote mechanical construction. Twist the wrench and pass it on.

  • forces sequential phases, “first we determine what it looks like then we figure out what it does.”
  • forces development in horizontal rather than vertical layers, i.e. “we’ve spent weeks coding but none of it does anything yet. We’re almost done though”
  • forces thinking in schedules instead of priorities, “I’ll have my part done in two weeks. What is it again?”
  • silos workers from each other, “What are you working on? Well, anyway, goodnight.”
  • ensures workers don’t have big picture, “Her copy doesn’t fit in my div based on his mockup. It’s not my fault.”
  • encourages hierarchies and coordination overhead (chicken husbandry), “My manager will get with your manager”
  • enourages narrow specialties instead of versatility and craftsmanship, “He does jpegs and gifs. She does html, css, and javascript. She does C# and Java. None of us actually build applications. By the way, did I already say it’s not my fault.”

Approval

    Distill complex interactions into a pretty picture. Take authoritative guidance from someone who’s only spent 15 minutes thinking about the problem.

  • encourages passive, diffuse product ownership, “you’re on the hook but they’re the deciders”
  • locks in premature commitments, “I put aside $10K for database integration”
  • invites arbitrary changes. “make this bit here blue”
  • creates low-value artifacts that lie, “sure it will work just like the wireframe.”
  • rewards promises over performance, “it will do everything I say, cost $40K, and be done in one month.”
  • bakes failure in, “how did we end up with this late, expensive hunk of junk?”

Getwith

    offensive getwith: “you need to getwith Joe on this.”

  • forces input from people with authority, no accountability and no direct contribution — like being made to run around with a target on your back
    defensive getwith: “Does Joe agree with this decision?” “I gotwith him on it.”

  • ask someone to attend one meeting, characterize them as agreeing with anything you do after that — like pulling a target of your back and sticking it on someone else’s

Any additions?

Women & Agile Development (revisit)

ACM Technews referenced this article from searchcio.com.au.

IT still trying to find what women want

The world is flat. Better go out and hire some women.

That seems to be the gist of a recent Gartner report on the gender gap in information technology

The article lists five gender-based traits CIOs should pay attention to when building IT staffs.

There’s a danger of drawing conclusions about individuals from differences in large samples. Just because men are statistically greater risk takers than women doesn’t mean I’m bolder than any particular woman. Or that she has better listening skills.

But at the level of an entire industry statistical differences are meaningful. Software would be better if we had collaborated and communicated better. Our products would be better if we had more empathy for customers and end users. Attracting qualified women into the field is a contribution to that end.

As the article suggests, the only appropriate way to do that in the context of a specific hiring decision is to include people skills as a requirement of the position, cast a wide net and hire the best candidate.

But you need to have a workplace and compensation package that is attractive to someone with people skills, technical chops and wants to give you their best at a sustainable pace.

To the argument that inviting women into a dysfunctional IT culture won’t make things better, I’d say that’s not my point. More women in IT is a hoped for result of humane workplaces — not a solution for creating them.

We have to work from within to make our companies better. In my software development team, our use of Scrum and XP has helped us do that. So far, my employer has been receptive.

I know that isn’t true everywhere. All I can say is those of us who have a choice sometimes have to make tough decisions about where we choose to collect our paycheck.