January 7th, 2012
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.
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.
(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.
(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.
(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.
(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.
January 6th, 2012
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
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.
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.
January 1st, 2012
September 27th, 2011
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.
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.
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.”
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.
- 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…
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.
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.
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.
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This topic was inspired by Samuel Florman’s book, The Existential Pleasures of Engineering
September 9th, 2011
My wife is reading from her diary for the week leading up to September 11, 2001.
World Trade Center was hosting a dance series. We saw Twyla Tharp and Ballet Trockadero on separate evenings.
Our one year old loved to walk around the courtyard, up and over benches circling the fountain and the globe at its center.
The underground shops and the Borders Books in building 5 were pleasant retreats from the late summer heat. On Sept 9th, I bought a shirt from the Warners Bros. Store in the World Trade Center shops with Wiley Coyote poised to plunge the switch on a bundle of dynamite.
You could get vertigo by pressing your back against the side of one of the towers and looking up. Nothing so tall was ever so flat. No edge to the sky was ever so perpendicular. The towers were not beautiful. They weren’t natural. But they were a force of mankind and beauty flowed through, around and above them.