These are notes from my presentation at the Hawaii International Conference on System Sciences (HICSS) #45.

I’ll link to my full paper when it is available and to subsequent posts as I publish them.

Agile values, product innovation and the shortage of women software developers Part 2 of 7

(11) Lost opportunity in the software industry (Product)

The lack of women on software teams is also a potential loss to product innovation…

(12) Women are our customer

Women directly or indirectly influence 61% of U.S. consumer electronics purchases[18].

(13) Women in gaming

Women are 42% of active game players and 48% of frequent game purchasers. And if you think they’re just buying them for their kids, industry research shows women 18 and over are 37% of game players whereas boys 17 and under are only 13%[19].

(14) Women on the internet

Half (50.4%) of the internet population is women 18 and over. They spend an average of 38 hours per month online. They spend 5% more time than men in online social networking and 20% more time on online shopping. Women account for 58% of internet buyers, 61% of internet transactions and 58% of internet dollars.

(15) Women are underserved

Software products are generally designed with no consideration for women as distinct user groups. In “Gender differences in Web Usability”, Frank Spillars states, “Gender differentiation is barely present in North American technology product design… let alone Web experiences[22].”

(16) how women perceive and use software

In “Towards Female Preferences in Design.” the authors found differences in the ways men and women perceive and describe software products. “The results of this research have revealed female-oriented themes that should… enlarge views of pleasurable product design attributes and language for the genders[23].”

(17) three ways companies fail.

Boston Consulting Group (BCG) highlights three ways companies fail to address women consumers: Poor product design: failing to tailor products to women’s unique needs and challenges.

(18) three ways companies fail.

Clumsy sales and marketing: based on outdated images and stereotypes.

(19) three ways companies fail.

Inability to provide meaningful hooks or differentiation: considering women indistinguishable from the general customer population or thinking of them as one monolithic segment[24].

Next: Can women devs help software better address the needs of women end users…

Previous: Are we driving women away from software development?

All slides published to date.

There is abundant research on the problems women face in our field. I would love researchers to jump in on whether Agile principles and Agile practioners can really make a difference.

I’d also love any suggestions of organizations, institutions and individuals I might reach out to for more information, collaboration, or to take up the cause.

Please comment on my proposal to Agile 2012.

The full citation list for my paper.

Short link: http://jkat.me/zb85T3

Tag(s): agile, agile-women-stem, Boston Consulting Group, Computer Science, developers, gender difference, hawaii, hicss, hicss45, Information Technology, Product design, STEM fields, values, Web Usability, women

Comments: 1

These are notes from my presentation at the Hawaii International Conference on System Sciences (HICSS) #45 on Agile values, product innovation and the shortage of women software developers.

I’ve broken the fifty slide, eighteen minute presentation into several posts.

This first part uses existing research to establish:

• women are under-represented in software development,
• this is a multi-decade trend atypical of Science, Technology, Engineering and Math (STEM),
• women are leaving mid-career in disproportionate numbers and
• young women are opting out as early as middle and high school.

I’ll link to my full paper when it is available and to subsequent posts as I publish them.

There is an abundance of research on the problems women face in our field. I would love real researchers to jump in on whether Agile principles and Agile practioners can really make a difference here.

I’d also love any suggestions of organizations, institutions and individuals I might reach out to for more information, collaboration, or to take up the cause.

(1-2) Hello,

My premise is the lack of women developers in the US is an impediment to value delivery and product innovation in the software industry.

In light of this, Agile principles call on practitioners to confront hostile workplace conditions and enterprises to address the material impediments of pay and advancement.

This beneficial change in teams and companies can incrementally change perceptions in the larger society.

(3) To introduce myself

I’m a software practitioner not a consultant or educator. I’ve studied and applied Agile methods for nine years.

I’ve spent most of my career in woman run organizations.

(4) I have a daughter

…who loves technology and sought out a culturally diverse, math and science school in Brooklyn. So, this topic is personal to me.

C. Hayes. “The Incredible Shrinking Woman” in Gender Codes : Why Women Are Leaving Computing. T. Misa, Ed. Hoboken, N.J. IEEE Computer Society, 2010, pg. 33

(5) Women are underrepresented in Computer Science

According to the US Bureau of Labor Statistics, women represent 46% of the workforce but only 25% of software developers. Over two decades the percentage of women developers has steadily declined.

S. Hewlett and C. Luce,. “The Athena Factor.” Harvard Business Review, pp. 51, Jun. 2008.

(6) Women are leaving mid-career

Women are leaving IT in larger numbers than men. 56% of women leave mid-career across all technology occupations. 41% leave their careers in “high technology” compared to only 17% of men. Half of women leaving STEM careers leave the STEM sector completely.

Four Decades of STEM Degrees, 1966-2004: ‘The Devil is in the Details.’” CPST, Sep. 2006, pg. 3.

(7) Women are not studying Computer Science

According to the Commission on Professionals in Science and Technology, in the decade between 1986 and 1995 the number of women earning Computer Science bachelor’s degrees dropped 55%. As of 2010, the percentage was still falling despite growing percentages of women graduating from four year colleges. This is not typical of STEM where 49% of bachelor degrees go to women.

N. Zarrett and O. Malanchuk. “Examining the Gender Gap in IT by Race” in Women and IT. J. Chohoon and W. Aspray Ed. Cambridge, MA. The MIT Press, 2006, pp.55-88.

(8) Young Women are disinterested in pursuing high tech education or careers

The Maryland Adolescent Development in Context Study, a longitudinal study of 1,400 white and african american students found that women were much more likely to have no interested in IT related careers and degrees than men.

(9) At what cost to the software industry?

In the last decade, the U.S. software industry represented $200B in annual sales and employed 2.2M software professionals. McKinsey & Co estimates in this decade, demand for mid-career IT professionals will increase by 25% while the available pool will decrease by 15%. This in a country where 71% of workers are in jobs with low demand or an oversupply of eligible candidates.

(10) The cost of attrition

And let’s also get at the cost of attrition. According to HR magazine, it costs approximately 100-125% of an employee’s annual salary to replace them. Retaining one-quarter of the women who leave computer engineering mid-career could represent a ten year savings of $8B to the industry.

Next: Are women are under-served by software…

The full citation list for my paper.

Short link: http://jkat.me/xzOjX7

Tag(s): agile, agile-women-stem, Bureau of Labor Statistics, Computer Science, developers, hawaii, hicss, hicss45, Information Technology, STEM fields, values, women

Comments: none

I presented my paper “Agile Values, Innovation, and the Shortage of Women Developers” at the Hawaii International Conference on System Sciences #45 (HICSS) on Thursday, January 5th. I’ll publish out my presentation notes in this blog over the next week. I’ll also link to the published paper when it is available on the IEEE website.

A puzzling experience

I’ve presented papers at HICSS before. Mostly in the Agile track chaired by Jeff Sutherland. I did present once in a more purely academic Ethics track.

In this case, HICSS had two “Agile” tracks. And the one I submitted to was actually not Jeff’s track. Kind of amusing. But also kind of NOT as the real reward of this conference has been the mix of educators and practitioners. By having two tracks, HICSS split the audience. I was in an academic track with an academic audience.

I am a digression

As the whole topic of Agile is a minor footnote at this conference, I found myself an outlier to the outliers. Or as the chair of my mini-track at this conference called my paper, “a digression”.

I will admit it. My paper is a digression. It was off topic here. It would be off topic at a professional Agile conference. That doesn’t make it irrelevant and I’m grateful for the reviewers who allowed it into the conference and the people who attended my talk.

It is about what our industry and our peers do to discourage and drive away women from software development and how Agile values can help practitioners find the courage and focus to fight this. Like I said, I’ll start publishing out my notes this week.

Just another process

I should have realized I wasn’t proposing into Jeff’s mini-track just based on the title: “Agile Software Engineering“.

Just the use of the word Engineering will inflame the passions of many very good Agile practitioners. I am not one of them. I understand “craftsperson” and “engineer” are freighted concepts. But I am the son of an Engineer and spent over ten years working in theater while becoming a paid software developer. I know that both terms imply a love of disciplined execution, a dedication to excellence, a sense of personal responsibility, and a society of peers.

However, in this case the phrase Agile Software Engineering spoke to an overall tone of the day I’d summarize as, “Really, agile isn’t so different from everything else. It’s just a process framework. Just some practices that apply in some cases and don’t apply in others. A good developer will do good work in spite of the process they use.”

The heart of my concern

This is entirely true if you focus on the practices but this characterization of the Agile movement gets to the heart of my concerns about widespread Agile adoption. Agile adoption isn’t about the practices. It’s about the principles behind the practices.

If you don’t have those values instilled into your team and aren’t working incrementally to install those values into your organization. You can call yourself agile but don’t characterize your understanding of what that means as the sum total of what Agile practice represents.

I don’t claim “Agile” is the one answer

It is clearly possible to build a team oriented, collaborative organization without calling your values, Agile.

It is also possible to get through life without wanting to work on a team or to collaborate with anyone. Not every software professional can or wants to embrace these values or would be successful if they tried. And you can build decent software in such a work place.

I also know there are now a plethora of shops that promote their “agile” process that wouldn’t acknowledge an Agile principle if it stood in front of them naked. They don’t give a rat’s ass about their coders — they consider team formation an org chart decision and wouldn’t tolerate self-organization for a second.

My path

But I know after years of hard won experience that Agile principles are my path to an empowered, humane workplace capable of producing work I am proud of that delivers for the business and addresses the needs of end users without exploiting and disposing of talented individual contributors along the way.

So, yes, some agile practices may be a prescription that can be applied selectively. But “Agile” as in the set of values I go to work with each day and come home with each night? That is me. Not my toolbox.

Short link: http://jkat.me/xho25j

Tag(s): agile, agile adoption, ieee, Jeff Sutherland, presentation, software development, Team

Comments: none

A second iteration of my 6 min. pecha kucha on why I believe Agile practice makes me a better, more joyful person. Presented at Agile Day 2011 for AgileNYC.

Download as pdf.

1
In pursuing agile practice I follow a family tradition of care and craft.

My mother is an immigrant. College educated but she made her living crafting the valences on fine drapery and upholstering furniture. She took pride in matching a pattern at the seams no matter how intricate. Her hands are wrecked from handling heavy fabric. Now she paints.

2
My father is a retired engineer who hobbies with an engineer’s precision — calculating how much steel to mill from the inside of a casting reel or the optimal temperature to anneal tempered fly hooks.

There comes a point where people offer to pay him for his hobbies. He moves onto something else. He does these things for pleasure.

3
My tween-age daughter aspires to be an engineer or scientist. She’s been on a Lego FIRST Robotics team since she was seven.

Her coaches wrote about her:

“You were chosen based on your ability to cooperate with others, problem solve, your endurance, care for the pieces, and enthusiasm for the task at hand.”

4
My girl is a born agilist…

Ten years ago, Agile was a word chosen to rally a community.

Now it’s a brand promoted as a tool that solves problems when it’s more essentially a set of values that encourage us confront problems.

We value…

5

• Collaboration over negotiation
• Working software over specification
• People over process
• Responding to change over following a plan

Let me tell you about my early experiences with specifications and plans…

6
Important people who don’t know how to build software but earn much more than software developers think big thoughts.
They call in other people who also don’t know how to build software but earn much less than software developers to shatter those big thoughts into a myriad small, literal and strangely ambiguous fragments.

7
Then we plan…

Humans adore plans… we worship plans…

A driver put her faith in her GPS. It told her to turn onto a bridge. Problem was the bridge had been washed away. Her $160,000 Mercedes was swept away and she had to be rescued as it sank.

8
The truth is people are inherently flawed. People are irreducibly complex. So is the software that solves their interesting problems. So while big ideas are great. Attempts to specify are great. Attempts to plan are great.

They’re just a conversation. They are not in and of themselves valuable.

9
I want to engage with people to navigate the imperfect world we see in front of us

Focus on what I did, what I’m doing and what I want to do next. To arrive at a desired outcome together and to continually improve how we work and relate to each other.

Because reality is serendipity and opportunity…

10
But it’s also setbacks, disappointments, and failure.

Failure isn’t any less awful when we refuse to see it. Worse is for failure to become, “the way things work around here”.

I accept failure. If we call it out, applaud the attempt and make changes so that we don’t repeat that exact failure again.

11
This openness to risk results in an iterative, reflective way of working I love because I dearly want to spend each day doing a little less crap and a little more not crap than the day before.

I want to achieve this by reducing the net crap in the world, not simply delegating my crap to others.

12
People…

There’s a Gallup study that claims the best and worst teachers, nurses, and policemen have more in common with each other than those in the broad middle. While the best are energized by their caring and use that passion to drive to the best outcomes, the worst are burnt and ruined by it.

The indifferent middle, they just crank along.

13
A practice that puts process over people constrains behavior to avoid failure without consideration for the individual. In a concern for consistency it prevents the best even as it attempts to avoid the worst.

The agile community is not immune. We’re so focused on scale and process recipes, artifacts and tools.

14
As if people are tangential. Easier to master than the software we engage with them to create.

Agile adoption in these terms becomes a mechanism for iterative mediocrity — a safe place for the indifferent middle.

I reject this.

Improving the workplace, improving worker satisfaction, improving collaboration is not a side affect of my agile practice. It is my practice.

15
I acknowledge that successful products can emerge from horrible workplace. And that that good workplaces can create failed products.

But a way of working that tears down talented people’s desire to build is tragic. It saps the world of its limited supply inspiration, creativity and joy. This is evil.

16
To combat this evil, my understanding of Agile principles requires honesty and trust among co-workers. A shared ambition to do better and be better while causing each other less unnecessary pain.

I focus on this in retrospectives, in one on ones, in coaching and in reflecting on my own decisions and actions.

17
The great thing about even striving after this goal is as you work towards it your co-workers will give you permission to demand more of them.

…just as they will demand more of you.

This demand gives you an angel on your shoulder. It inspires even as it shames you into action.

18
This isn’t easy. It is mortifying to confront your own limitations and the limitations of others.

But the action isn’t to change who you are. It is to adjust specific behaviors one at a time in the larger interests of the people you work with and the work you do together.

19
The reward is that you get to be the same person with your boss that you are with your co-workers that you are with your staff. A person you can wear home. A wiser, better person than you were last month or last year.

This is a path my mother and father lay down for me and one I wish for my daughter.

20
I don’t merely want success on a project or a job. I want to spend my life loving what I do. I want to be proud of my accomplishments,

…And I want to be proud of who I was as I attained them.

This is the existential joy I get from Agile practice.

Thank you.

Short link: http://jkat.me/pNcdrM

Tag(s): Agile Development, AgileNYC, scrum, values

Comments: none

I just submitted a paper on agile values and the underrepresentation of women in software development.

This is not an original topic but the research I’ve read has focused on how women who participate in agile practices, particularly XP pair programming have more favorable impressions of the work and of their ability to contribute both of which are correlated to entering the occupation.^1,2

My belief is that agile practices are tools but it is the agile values that give us the urgency, courage and insight to wield those tools towards a desired outcome.

That is, we are much more capable of making software development more tolerant and inviting of diversity if we believe we should do this as part of our core mission as Agilists to develop with craft and quality and to deliver value to our employers and our end users (do not forget).

So, the rough outline of my paper is this:

• The shortage of women entering software development and disproportionate share of women leaving mid-career is real and measurable and well documented.
• The problem is worse in IT than it is in almost all other areas of STEM because, unusually, the percentage of women in software development has actually declined over the last 20 years.
• This shortage and particularly the attrition of experienced women developers represents a material burden to our industry.

• Product teams that represent the diversity of their customers have a potential advantage in developing products that appeal to that diverse customer base
• Women are at least the equals of men when it comes to influencing consumer technology spending and online activity
• Therefore, it is in the interest of the industry to educate, recruit and retain women developers

• Agile is a collection of practices united by a coherent set of principles
• As agile becomes mainstream it is more important than ever that practitioners understand and embody these principles
• The creators of the Agile Manifesto realize this and are calling us to a principled approach to our work
• These principles are at stake when it comes to things that affect the competitiveness, insight into end users, and potential for innovation in our teams
• If we engage our agile practices behind this principled cause we can begin to remove the impediments within our own organizations to the recruitment and retention of women
• When we do, we will influence larger changes across the industry, within education and in society

I’ll go into more detail and try to defend my arguments in later posts. In the meantime, I’m happy to engage with anyone who finds fault in my premise.

¹S. Berenson and K. Slaten. “Voices of women in a software engineering course” in JERIC, vol. 4.1, Mar. 2004.

²O. Hazzan and Y. Dubinsky. “Empower Gender Diversity with Agile Software Development” in Encyclopedia of Gender and Information Technology. E. Taugh, Ed. Hershey, PA: IGI-Global, 2006, pp 249-256.

Short link: http://jkat.me/jZqQpF

Tag(s): agile, Agile Manifesto, pair programming, principle, women

Comments: none