The Buddy System for Working Moms

Madeleine Albright said, "There is a special place in hell for women who don't help other women." Her intention was to point out that women as sisters should help each other succeed. Successful women have an especially high burden in this regard. To me, her comment seemed to be directed at individual women. A couple of things that I read/heard this week made me wonder if this should be directed at the structural and social arrangements that we have. In other words, we as women need to systematically seek each other out to be partners and help each other succeed in the workplace. I give you two very different examples to illustrate, one from a former professor and one from an officer in the Navy.

A personal essay by Kathy Weston appeared in Science recently. She is a science writer, who used to be a professor at University College London. After 20 years in her position, a Research Assessment Exercise deemed her contribution to the department to be inadequate. She left before she could be fired. Her career started off well enough, but her research projects became more modest and unambitious over the years. The causes included the competing attentions of family and her own self-doubt. One paragraph of the essay especially caught my attention.

Trying to run a lab full time with small children at home is very likely to result in a drop in research productivity or quality, and yet little allowance is made for those of us, mostly women, who find ourselves in this situation. I believe I could have run my lab very successfully if I had been permitted to job-share with a close female colleague, also with two young children. Between us, we could have covered all the bases, and perhaps as a team we would have retained our competitive edge and hence our enthusiasm. This just does not happen in the male-oriented world of science in which, traditionally, dogs are keen to dine on dogs rather than share the bone between them, so to speak.

And the part about collaborating with a female colleague is important. While sharing a lab with a male colleague certainly would be beneficial, he would not be feeling the same pull from home and pressure to perform at work.


Petty Officer 1st Class Sheena Sullen was the subject of an story on NPR this morning. She had enlisted in the Navy and was about to be deployed on a missile destroyer. Her fiance had already been deployed, so there was no one available to look after her two children, ages 14 and 8. Sullen made a call to her childhood friend, Jihan Sanders. After careful consideration, Sanders quit her job and moved into Sullen's home in another state along with her own children, ages 12 and 9. It's an incredible act of friendship-- in both directions.

For Sanders, it is a privilege to be a temporary mother, as Sullen had been to her. "I never had a mother, so I didn't know what it was like, even how to act like a girl," Sanders says.

Sanders is helping Sullen at home, so Sullen can succeed at her job as a Naval officer. If Sullen could not have deployed, it would have been the end of her career.

What if women could have buddy systems that were not ad hoc? What if it became the norm for women to find other women to help them run households and research laboratories? This pairing up would have nothing to do with romantic relationships (and would probably be better if it didn't). It would be more like a sister than a mate. I don't want to suggest that Weston would still be professor if she had a buddy to share her lab. Her story could have done in any number of directions. But it would have helped, and it would probably help women, including me, would benefit from an arrangement like this.

And as a special bonus, that special place in hell would be a lot smaller.

The Scrum Mistress' Guide to Standing Up Daily

This is my second of two posts on my experiences while attending a CSM course. The first post appeared a couple of days ago.

Just before lunch on the second day, Mike wanted to do a short exercise on running daily stand up meetings. He asked for a volunteer to be a scrum master. I paused a moment to give other people a chance to have the educational experience, before I enthusiastically put up my hand. Although I've studied scrum, I've never actually had a chance to use it.

After I trotted to the front of the room, Mike started to look for other volunteers. He jokingly said that it would be fun for everybody except the scrum master. He handed an index card to each of the volunteers, who joined me at the front.

I wondered what was on the cards. Could it be the user stories that they were working on?

When we were assembled, Mike stepped out of the way and told us to have our meeting. I turned to the group and they all started talking at the same time. I thought to myself, "Oh, it's like that is it?"

I started to pull out my various tricks for crowd control. In my day job, I teach classes of 50-100 undergraduate students. There's always a joker/talker in the class. Also, some days are more difficult than others. It's like a whole bunch of them had something in their breakfast that made them extra fidgety and extra talkative. Here are some of the strategies that I used.

• I put my hand up, way up, to get attention. I'm about 5 feet tall (~150cm), so putting my hand up gets it about eye level for most of the guys. This is the universal signal for I have something to say and it usually gets people to stop talking for a split second, so I can get a word in edgewise. As a woman, one must never shout, because one ends up sounding shrill.
• I used my eyes to place a laser-like focus on the person who was supposed to be talking. The other team members will use my eyes as a cue for their attention as well.
• I used my aerosol can of "ssh" (in the style of Austin Powers) on one particularly disruptive team member.

I managed to get through all eight team members in under ten minutes. I managed to connect four people who needed to have a side meeting and arranged a follow-up meeting with a team member who was heading off on their own direction.

Needless to say, I had a lot of fun. A lot of these tactics are very heavy handed and I wouldn't necessarily use them in a normal team situation. I definitely took advantage of the fact that this was a classroom exercise that involved role-playing. In an actual work situation, I would let the team have some runaway meetings, maybe have a meeting where we discussed protocols for daily standups, and met one-on-one with the most problematic team members.

At the end, Mike said, "Wow, you got them through it. Susan is small but scary." He also asked the group if the meeting looked familiar. A number of people in the class, all of them women, agreed enthusiastically. One woman said that the exercise was too close to home.

I was taken aback by this. I had seen some daily standups led by a woman, where the team members were infantile and even rude to the scrum master. But I always thought that this was an exception. So, I started to wonder.

Do women scrum masters encounter special challenges because of their gender? How many of you out there are dealing with unruly meetings? Do you have an advice or war stories to share?

When should we be using pair programming (or writing)?

I attended Certified Scrum Master training with Mike Cohn last week. I have been teaching agile and scrum to undergraduates for about six years now and I thought I should finally get my certification. Although I had the "book knowledge" down pat, I learned a lot from the Q&A and from the conversations that I had at my table. This post is the first of two that I will be writing about my experiences.

One of the people at my table was Andrew Mutz, Director of Software Engineering of AppFolio in Santa Barbara. He joined his organization two years ago and has been using scrum since then. I used the opportunity to pick his brains about his experiences. I was impressed by the software development practices that they use at his organization-- Lots of common sense and a good balance between engineering principle and business goals. (They're hiring, by the way.)

We got onto the topic of pair programming. We both agreed that there were many good things about pair programming. Appfolio has all new hires pair for the first three months or so. I didn't mention this at the time, but there are research literature to support some of our intuitions. Laurie Williams, Ron Kessler, and Ward Cunningham had a paper in IEEE Software in July/August 2000 on "Strengthening the Case for Pair Programming." They reported on studies by other researchers and their own work. Pairing increased the effort (person-hours) by 60%, but reduced the timeline (elapsed time) by 40%. Programmers produced higher quality code (pass more test cases), were happier, and were more confident.

We also agreed that not all tasks benefited from pairing. There were some tasks that were so simple (tedious?) that having another pair of eyes was not helpful.

However, we disagreed on the value of pairing on difficult tasks. Andrew argued that the value of pairing diminished with more complex tasks. Consequently, the graph of value vs. difficulty would look like a typical ROC (receiver operator characteristic) curve. This line is shown in blue in Figure 1.

Figure 1: Difficulty of Task vs. Value of Pair Programming

My impression was that the value of programming increased along with the difficulty of the task. This line is shown in green in Figure 1. Most of my direct experience with pairing is in writing and brainstorming research. But it's also based on conversations that I have had with professional developers who use pair programming. It's entirely possible that Andrew is right and I just haven't experience the top end of the difficulty axis.

Our conversation went on and we also agreed that pairing would be less useful for program comprehension, i.e. trying to understand an unfamiliar code base, if we used the conventional model. However, if we could have two people working side-by-side with a computer each, it might be useful to pair. On one occasion, I was working with two students to come up with a research question for a grant proposal. We were sitting around a table, each with our own computer. We went through cycles of brainstorming, critiquing each other's ideas, and doing searches of the academic literature to see what had been done before and to get new ideas. We managed to eliminate a lot of dead ends quickly.

I'm sure that there are other situations that are worth discussing.

What do you think? When should we be using (or not using) pair programming?