Heather McLean

As one of the rare female members of the IT workforce, I can always support the inclusion of more women. Thus, I applaud Microsoft’s investment in the National Center for Women & Information Technology. Sadly, after reading some of the comments to the article, it becomes blatantly obvious why women tend to avoid IT. You can see some of the very best in male chauvanism:

From aptly named “Anonymous Coward”:

“and they are innovative technical thinkers”

I love women as much as the next guy. Women have their role in society, but innovative? In 28 years in IT I’ve never seen a woman come up with an answer to a difficult technical problem that she’d not read somewhere.

From “Brian 29,” obviously trying to be funny but exemplifying how a lot of other men see us:

I saw the headline in my rss feed and thought this would be about booth babes. I was a little disappointed, but I guess I should have known better when it didn’t say NSFW….

At least “TW Burger” admits what he/she says is sexist, I think trying to be insightful, but really just advocating pushing us into “traditionally female” roles:

I can not comment in any way, shape, or form without sounding like a sexist pig. However, here goes: Reverse/Positive discrimination grants like this are usually is the brain-child of someone with a single minded agenda that ignores that the money would be better spent elsewhere. There are very few women in IT because they do not want to be in IT. Spend the $1 million on getting women into careers they want. Daughters of rich families do not become assembly line workers, maids, or receptionists. I can foresee this money being ladled onto women who do not need the cash or those that would not normally take, and have no real interest in, IT taking free courses simply because it didn’t cost anything and would look good on a resume.

Steve Roper on the surface makes what would seem to be a logical point, but he also forgets that men are already in a position of power, making it less appropriate to give them certain kinds of assistance:

… Feminism isn’t about *equal* rights, it’s about *women’s* rights. That’s why it’s called FEMinism.

A few years ago we had a similar campaign here in Australia to get more men into teaching positions and the government proposed a subsidy for men entering teacher-training courses. What happened?

The whole scheme was kiboshed within weeks of the proposal by angry feminists in the Education Department and the so-called “Equal Opportunity” Commission, who called the scheme sexist and discriminatory against women. They did not, however, utter so much as a squeak when TAFE (technical college) started an equally discriminatory program to get more women into the IT courses. But such double standards are par for the course these days.

Anyways, there are dozens more that you can read at the Register. It is these attitudes that cause women not to want to enter IT (or any predominantly male profession, for that matter), not any lack of ability or interest. Males in large groups tend to create a hostile environment for women, either by cause or accident. Sometimes it’s just being complacent without realizing what you’re doing. It can also start with a girl’s parents steering her away from “un-lady-like” professions, stunting her opportunities from the very beginning.

As a general disclaimer, I will say that I have had the pleasure of working with many wonderful men over the years. I’ve had many supportive male colleagues. I don’t want it to seem like I’m blaming the entire male population for the transgressions of a select few. On the other hand, I’ve also had to deal with a few not-so-stellar individuals who have done a range of injustices such as downplaying my contributions to the team simply for being a woman, patronizing me, and even sexual harassment. These few heartbreaking encounters can really color the experience negatively.

I’ll admit this is a little bit of geek porn today, different from my usual fare. Google has released a new algorithm for sending software updates dubbed Courgette. In particular, I found the section on “guessing” intriguing:

We can think of a differential update as a prediction followed by a correction, a kind of guessing game.  In its simplest form (just bsdiff / bspatch), the client has only a dumb guess, ‘original’, so the server sends a binary diff to correct ‘original’ to the desired answer, ‘update’.  Now what if the server could pass a hint that could be used to generate a better guess, but we are not sure the guess will be useful?  We could insure against losing information by using the original and the guess together as the basis for the diff…

This system has some interesting properties.  If the guess is the empty string, then we have the same diff as with plain bsdiff.  If the guess is perfect, the diff will be tiny, simply a directive to copy the guess.

A predictive software update engine has some interesting potential. I would love to see with what kind of accuracy their algorithm can actually “guess” the correct patch.

Dave Rooney made an insightful post today regarding what happens in an agile team under pressure. Essentially they revert to their training, or to make it more simple, they revert to whatever their naturally formed programming habits are.

How does [an emergency] apply to software development? Well, consider the poor overworked software developer. They’ve had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster … Near the end of the sprint, this poor developer is running out of time and still has work to complete – they are facing an emergency! So what do they do? They revert to their original training.

What was that training? … They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? … In the end, the attitude is to get something – anything – done in order to get the marks.

This was espoused in a previous workplace of mine as the concept of “get ‘er done.” What upper management was trying to address was an apparent lack of progress and too much time wasted on best practices. What this generated was an urgency of get as much done as fast as possible, and the result is catastrophic. People burn out, product quality takes a nose dive, and in the end, you’re in a worse place than when you started. “Get ‘er done” is almost as ineffective as “get nothing done,” simply because in the end the result you get is so poor that you don’t want it anyways.

This is such a flawed mentality to begin with that it’s difficult to address it; you pretty much have to change the attitude from the top down. Management must be understanding of the time it takes to produce quality over quantity, while developers must be willing to eliminate wasteful activities (that they may not agree are wasteful), and the Product Owners and Scrum Masters must assist the teams with committing to a reasonable amount of workload. This is partially a training issue and partially a culture issue. Training can be used to instruct change, but the participants must be willing to enact change.

The next meeting of the Fort Worth APLN is on June 11, 2009 at 6:30 PM. From the summary:

Based upon last month’s speakers topic ‘Speed bumps – Challenges on the road to Agility’, we thought we would pull three Bumps and discuss in small groups.

The selected bumps will be:

• Team Organization
• Story Points and Velocity
• Sprint Planning

As usual, if you want more information, contact Charles Seaman at fortworthapln@gmail.com.

I’d like to take a moment to talk about a style of management I call the “just deal with it” approach. It’s an all-too-common situation that happens in highly structured organizations, and the really sad part is that it is self-defeating for the people who are perpetrating it. The scenario plays out something like this:

1. Executive Management sets goals for the month, quarter, year, whichever and communicates them to Vice Executive Management.
2. Vice Executive Management wraps those goals up with additional goals of their own and communicates them to Management.
3. Management now has goals that it had no say in developing but must somehow meet with the resources/time at hand. Those goals are communicated to Implementation.
4. Implementation (developers, business analysts, quality assurance, etc.) receive a set of goals that seemingly come out of nowhere and have no relationship to the reality of what they will have to implement.

Do you see the fatal pattern here? Communication and goal-setting goes one way… from the top down. It’s a “trickle-down” form of setting commitments. This results in a multitude of consequences:

• Management and Implementation are frustrated by the lack of involvement in setting their own commitments and deadlines.
• Execute and Vice Executive Management are frustrated by deadlines that constantly slip or bring less-than-promised deliveries.
• The only motivation for Management and Implementation to meet goals is to avoid pressure from the higher levels.
• Implementation has two choices: miss deadlines/under-deliver or burn out trying to “crunch.”
• No one feels like communicating with each other because everyone sees everyone else as “the problem.” This is often the part where the sentiment of “just deal with it” crops up, as everyone from the top down is expected to deal with what rolled downhill rather than fix the problem.

It’s a cyclical beast; as soon as one set of goals are missed, a new set is sent down the pipes. The upper levels take a fire-and-forget approach, and then they are left wondering why that approach didn’t work. If you tell a subordinate to do something, they should just do it, right? I don’t mean to be overly critical of upper management, but keep in mind that this is a post about management techniques; I’m going to pick on those who earned it. To be fair, however, this doesn’t happen because the goal-setters are inhuman monsters who want to drive their subordinates to madness (well, I would hope, at least). It happens because there is a fundamental misunderstanding of how to properly set company- and department-wide goals, especially with regards to product development.

The most important thing to remember is that the goals you are setting are not just your goals. Mr. CIO is not the only one who will work on them, so he should not be the only one who determines what they are and when they will be delivered. I’m not advocating that you include junior developers in board meetings, but it is important that the lower levels of management and the implementers are involved at some point in the process. Go to your subordinates and say, “Hey, this is what I want to accomplish. How do we do that and how long do you think it’ll take?” This will build goodwill and will also open your eyes to a whole new level of complexities that you may not have seen before.

Most upper management takes the first step, presenting the goals for evaluation to their direct reports. This is good, but at some point you have to reach the lowest levels. The people at the bottom are the ones who will be building your products, so they are the most likely to know all the intricacies of making your goals happen. You may not realize at surface analysis that adding a single button to an extant dialog is actually 3 weeks of work instead of 3 days because of mitigating circumstances and quirks of the platform. To be fair, it’s not your job to know those things; thus, you need your product teams to help you out.

Also, if your implementers are involved, a miraculous thing happens… they begin to care. It’s very easy to blow off deadlines and such that are deemed “unreasonable” and handed down from the top. But if a developer tells you that something is going to take 5 days to complete, suddenly the onus is on him to meet his commitment, and he’s more likely to put in extra effort if that deadline slips.

There is a win-win scenario to this situation, and it nets you two very important results: more accurate/realistic deadlines, and a workforce that will actually put forth genuine effort to keep those commitments. It just requires you to literally turn your thinking upside down.

Our previous set of status meetings failed to be productive. They lasted at least an hour every day, often more than that. They were unfocused, and often crossed so many topics that no one really remembered what happened after they left the room. Eventually, they just kind of petered out… no one really wanted to attend them anymore, as they were obviously unproductive. The period that followed was almost as bad–no daily status, but at least people had more time to do actual work. Tasks were slipping through the cracks and overall communication declined.

So I was happy to step in with an alternative solution: a Scrum-like daily status meeting. I don’t make people stand-up, and we’re time-boxed to 30 minutes instead of 15, but otherwise the principles are the same. At each meeting the attendees are required to come prepared to answer the usual triumvirate of questions:

• What did you accomplish yesterday?
• What are your goals for today?
• What issues are affecting your ability to meet those goals?

I’m pleased to say that even after only one week, the system has proven effective. People don’t mind attending since it’s short and focused. We stick to the agenda above; we’re not quite used to the format yet, so some side discussions occur in the middle of the meeting, but we’re getting better. Now everyone knows what everyone else is doing, and communication is improving. We’re catching issues much faster since the team is aware of what is going on before it happens.

I won’t claim daily status is a panacea, but it’s working for us with remarkable results.

Shameless plug for the new Fort Worth chapter of the APLN. It will be 6:30 – 8:30 p.m. on April 16, 2009. The speaker will be Ash Tengshe from Capital One Auto Finanace. Attendance is free. If you’d like more details, please contact Charles Seaman at fortworthapln@gmail.com.

A while back, Mike Cohn posted a concise explanation of how story points relate to hours. It’s a common phenomenon; folks who are used to traditional project management really want those points to equate directly into, “how long will this take?” The important thing to remember is that story points are a measure of capacity and effort, not time. The next thing to remember, and this really messes with teams new to agile methodologies, is that story points are mostly meaningless until you have accumulated historical data. Without some data on trends, a story point really is a guess; what does 1 point mean versus 8 points when this is your very first iteration? You have to go on gut feelings, and there will be resistance to that kind of “guesstimation”—which is pretty sad when you realize that guessing hours is not much better than guessing points.

At least with the points, you’re admitting that it’s an estimate. Hours tend to lull people into a false sense of security, assuring them that this is the timetable, and if you deviate from the established time line, then it’s the implementers’ faults, not the estimators’. Which brings me to another important part: story points are estimated by the team, not by a single project manager dictating from on high. This puts the onus on the team to estimate better with each sprint (which they will, given the freedom to do so), instead of being forced into a death march to meet arbitrary time limits.

Estimating story points is an ongoing learning experience. You start with none and build from there; once you’ve had three or four iterations under your belt, you’ll notice the team getting more accurate. All one point stories will start to look similar and take similar amounts of time, and once you have that in your arsenal, estimating with the story points both generates a realistic timeline and gives your team some breathing room.

So I’ve gotten really used to the idea of thinking in terms of individual stories/tasks when I work, and I like the visual cue of a task board. I haven’t been able to convince everyone that this is the best idea yet, so I’m leading by example. Here’s a shot of my “personal task board” that I have in my workspace.

Personal Taskboard

You can see several columns from right to left: NR (not ready/undefined), Rdy (ready to implement), WiP (work currently in progress), and Done. The tasks are written on individual sticky notes with a description, the ID number from our defect tracking system (if any), and the product release it is assigned to (if any). They’re assorted roughly in priority order with higher priority items towards the top of the board.

I wanted to take a minute to pass on a very insightful article by Tobias Mayer:

Oppression, Revolution and the Future of Scrum

I won’t add any commentary this time, just go read it for yourself.

As an aside, I realize that this is a pretty weak post in light of my long stretches of silence. My current project has me pretty busy, but hopefully I will have some more discussions on agile and whatnot in the near future.