We need more women in tech.

Women are just as good as men in tech.

I have spent over fifteen years in the technology business as a consumer, developer and scrum master. One constant during my career is that there are not enough women working in technology. Numerous articles have been written on the subject and plenty of initiatives are bubbling up around the web to teach women to code.  Still, I want to address a few of the myths I have heard about women and technology which need to be discredited.

1)Women are not logical enough to code.

This is false.  The American Psychological Association states, “…gender differences in math achievement are largely due to cultural and environment factors” (emphasis mine).  So given and equal level of training women and men are equally good at math and by default logic.

2)Women cannot work the log hours required of programmers.

This is a cop out for two reasons.  First, working more hours does not guarantee better work.  According to the Harvard Business Review the more hours a person works the less productive they become.  Second, long hours are often a failure of project planning and business leadership. Individual developers should not have to pay the price for bad planning.

The above said, working extra hours and being involved in crunch time is a perverse badge of honor.  I like it when the Netizen Corporation Blog says, “This is a representation of failure rather than commitment.”

Having women in the office particularly women with families lives tempers this desire to work insane hours as a form of perverse competition.  When you have lives outside of work it tends to make that labor more productive.

3)Women hurt the teamwork of the development crew.

Study after study has shown diversity of gender, race and religion yields better decision making.  If anything software development is about making decisions.  People do feel discomfort when thrown together with groups they are unfamiliar but one they get over that discomfort their performance improves.

I have experienced first-hand the change which takes place when women are added to a development team.  Jokes about alcohol consumption and romantic conquests go way down.  The men on the team care more about their hygiene and appearance.  Everyone becomes more polite and professional with each other.  Finally, disagreements are worked out in a more civil fashion.  It is not perfect but it is much better than working on all male teams.

4)Women are just not as knowledgeable.

There are plenty of women in technology who have fantastic skills.  Marissa Mayer did not graduate from Stanford and become and executive at Google because of her good looks.  She was a smart and capable engineer who also brought to the table a keen sense of design and a fanatical devotion to metrics.

From a more personal perspective, Angela Dugan author of the “The TFS Whisperer” has become a role-model and big sister of sorts.  She introduced me to TFS, Agile, and better development methods.  She leads the Chicago ALM group and has a profoundly strong reputation among the development community around Chicago.  I have known Angela for over five years and I am better technologist because of it.

These two women are just some of the people I know who bring a sense of craft and commitment to their technical skills.  This just confirms to me that you do not need to have a UNIX beard in order to be knowledgeable.

Technology needs more women but some of these myths I have attempted to discredit have gotten in the way.  If this situation is going to improve men and women are going to have to step forward and quash these faux myths of male programming superiority.  Otherwise we will continue to be stuck in the same destructive patterns we see today in the world of development.

Until next time.

It is always something

It is always something.  Being a scrum master
requires a good sense of humor and great deal of self-reflection.

Like many people from Generation X I did much of my growing up during the 1970’s and 1980’s.  One of my favorite celebrities of this period was comedian Gilda Radner from the original Saturday Night Live cast.  She was taken from us far too soon by cancer but she was inspirational in how she lived her life.  She used to say, “It’s always something” with a wry smile and discuss the absurdities of life.  It became the title of her autobiography and for those of us who work as scrum masters we should take it as our personal mantra.

Scrum Masters are confronted daily with numerous problems and have to address them.  In the agile world we call them “impediments” but the reality is they are problems making it difficult for the team to meet its sprint goals. These problems could be developers not getting along or they could be systematic having upper management buy into the process.  It is late nights with developers burning the midnight oil and early mornings taking phone calls with off shore teams.  It is being positive when you have no logical reason and always coaching others to be better.

I have wanted to be a scrum master for over four years and I leaped at the chance when it came along.  Now that I have become one my early enthusiasm has transformed into quiet stoicism.  Each day my team is judged on the software we ship and the value which we provide for the business.  There is always a daily crisis of some sort.  There are millions of dollars in revenue at stake and never enough time to do things.  Under these constraints, it takes a good scrum master to get his team to perform.  I am working toward being a good scrum master.

Until next time.

Do Not Kiss the Cobra.

Incentive programs are just as
 misinformed as kissing a cobra.

As a leader you are faced with countless decisions.  One of those decisions is how you create constructive incentives for your team.  This week on the blog I would like to talk about one of the most dangerous traps you can get into as a budding leader.  The Cobra Effect.

The cobra effect is documented around the internet but in short is a classic example of the rule of unintended consequences.  Simply put, when you put an incentive out to guide the behavior of co-workers or subordinates you will find they will game the system to maximize the incentive for their own personal interests.  This was documented when the English ruled India as a colony.  A local governor offered a bounty to reduce the number of cobras in the city of Delhi.  It worked too well and the locals started breading cobras to kill them and collect the reward.  This bit of capitalism got the governor to cancel the bounty.  In response, the cobra breeders released their worthless snakes out onto the streets.  The net effect was an increase in the cobra population of Delhi.

As a scrum master or leader you can run into the cobra effect at any time.  For instance, if you want to increase the velocity of a team the team members could inflate their estimates making it look like they are doing more work than actually doing it.  My favorite example comes from the comic Dilbert where the pointy haired boss offers to provide bonuses for developers who fix bugs.  The developers use this as an incentive to write buggy software to increase their compensation.  

The short answer is that incentives are not a good tool for improving performance.  People will change their behavior temporarily in order to meet the incentive goals and then when the incentive goes away they will switch back.  This means that developers and business people will take shortcuts instead of doing the job the way it is supposed to be done.  Long range goals are sacrificed for short term incentive gains.  I also feel that quality suffers.  

So when coming up with incentives for your development team and business, take a pause and understand that you are inviting a snakebite from the Cobra effect.  

Until next time.

Self Organization and Boundaries

Boundaries mater in Agile

Being a Scrum Master is hard work.  You spend a lot of your time helping others and many times wind up acting as a therapist for the people on your team.  You massage egos, help with nagging insecurities and keep fear and uncertainty at bay.  It is the most rewarding and the most frustrating things you can do.  The most interesting thing I have found over the last few years is it also requires some firm leadership and boundaries.  This week I would like to talk about that discovery.

As I usually do, I spend a great deal of time surfing the web learning about technology and gathering up new ideas to lead my team when I stumbled on to an article in Slate.  Laura Smith in her article “Why I Regret Being a Nice Boss,” spoke about her experiences running a coffee shop in Washington D.C. What struck me about the article was the realization that as a leader some things were just not negotiable.  Employees were expected to be on time and each employee had a set number of minutes for break time.  Those who violated these non-negotiable rules were written up and eventually managed out of the firm.

This made me think about agile principle number eleven, “The best architectures, requirements, and designs emerge from self-organizing teams.”  How can a leader set non-negotiable terms and still allow a team to self-organize?  This is when I realized that when a business or leader sets something as non-negotiable they are really setting boundaries.  Once a team understands what the boundaries are they can organize within them.  For example, a sprint is always a fixed length.  This means all work committed to by the team must be finished by the end of the sprint.  How that work is divided up and managed by the team is up to the team but the work must be finished and that is non-negotiable.

During a sprint the team decides what a good definition of done is.  For the teams I work on, it is the following; unit tests written, code which compiles, code checked into source control, and code pushed to our development environment.  If this this definition is not met then the user story is not “done” and the developers have to go back and finish the work.  This creates some tension with meeting all the sprint goals but it has saved my team numerous hours of headache over the months.

Once the sprint is done, we have used our retrospective to tweak the definition of done for the next sprint to make sure that we are improving.  This keeps with agile principle number twelve, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly.”

So being a firm, fair therapist is what you should strive for as a servant leader of your software development team.  By setting boundaries, you give your team a safe place to experiment and thrive.  You also create an environment where everyone knows what is expected and how they can succeed.  This isn't always the nice approach but it will make everyone feel better at the end of the day.

Until next time.