Antidote the diving catch culture of heroics and privileged roles

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 6 of 7


(37) Antidote the diving catch culture of heroics and privileged roles

“Many SET cultures place a high value on risky behaviors: They celebrate heroic diving catches made at the eleventh hour to rescue a failing project”

(38) Problem statement

“Why don’t we just build the system right in the first place? Women are much better at preventive medicine. A Superman mentality is not necessarily productive; it’s just an easy fit for the men in the sector. Because it is generally men who are making the promotion decisions, they recognize this behavior and reward it.”

(39) Collective ownership

Supporting that sentiment are the following Agile principles: “Continuous attention to technical excellence and good design enhances agility.” “Simplicity–the art of maximizing the amount of work not done–is essential.” What I’m getting at here is an emergent property like self-organization called collective ownership It’s an outcome of teams that embrace Agile values of self-organization, quality and simplicity.

(40) What collective ownership feels like

“Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes[50].”

(41) Practices that support collective ownership

Collective ownership is the engineering expression of self-organization. To achieve collective ownership, a self-organized team should explore disciplined, collaborative engineering practices: pair programming, evolving architectures with refactoring, frequent integration, unit testing and test-driven development[53].

(42) Why is collective ownership an antidote to heroics?

A diving catch implies a single set of eyes on code. It implies haste and a need for emergency intervention, i.e. poor quality. Emergency code is not unit tested, it is not elegant. It also implies a team that is not pulling together to deliver the goals of their iteration.

(43) Why is collective ownership an antidote to special job assignments

Collective ownership discourages the use of specialists which represent bottlenecks and opaque stores of tacit knowledge. The Scrum guide includes as the basic definition of team, “There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either[52].”


Next: How values create change from small networks to large…

Previous: Antidote to hostile workplaces and the alpha geek

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.

Do Agile principles demand we confront the shortage of women developers?

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 4 of 7


(23) Agile Software Development

Now let’s incorporate Agile Software Development into this. What unites the different agile methodologies is a shared set of values and a shared cause to change the way software is made and delivered to customers. These values are declared in twelve principles and summarized in a four line manifesto…

(24) High level principles

We value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

(25) Agile values are the foundation of agile practice

“These values are not just something the creators of the Agile Manifesto intended to give lip service to and then forget. They are working values. Each individual agile methodology approaches these values in a slightly different way, but all of these methodologies have specific processes and practices that foster one or more of these values.” – Jeff Sutherland

(26) Agile values as a standard of conduct

Agile principles and the ongoing discussion of them form the basis for a normative standard of conduct informing how practitioners should behave towards our work, our peers, our employers, our customers and our end users. They challenge practitioners not to a narrow definition of success on a task but to craft with quality, to collaborate in high trust, to cede authority to individual contributors, and to work with the customer’s interests in mind, to make predictable progress at a sustainable pace, and to make problems and opportunities visible.

(27) Agile values as a call for beneficial change

Agile principles urge us to inspect our actions, confront impediments, and drive towards beneficial change. And the means to this is, as Alistair Cockburn suggests, we “…value agile principles over the agile practices[38] Or as Bob Martin says, Not simply to execute but to take care.”

(28) What Agile principles demand we confront this problem?

So if Agile practitioners recognize the shortage of women in our shops is an impediment to value delivery – that it is an obstacle to our mission as agilists – then we will work to remove this impediment. The question becomes “What Agile principles demand we confront this problem?” In the interests of time I’ll highlight two hostile cultures described in the literature and the agile values that challenge them.


Next: Antidote to hostile workplaces and the alpha geek…

Previous: Can women devs help software better address the needs of women end users?

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.

Can women devs help software better address the needs of women end users?

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 3 of 7


I. Nonaka and H Takeuchi. The Knowledge Creating Company. New York, NY. Oxford University, 1995

(20) How would having women on dev teams help software better address the needs of women

For this, I’ll lean on the research of Nonaka Ikujiro and Takeuchi Hirotaka . This slide is an illustration of their concept of the product development cycle in serially innovative companies. It requires the creation and sharing of two kinds of knowledge within the organization. Explicit knowledge – that which we can explain in words – and tacit knowledge – that which can best be expressed by doing. This concept of knowledge creation and techniques for forming teams that support it are the roots of the most widely adopted Agile process framework, Scrum[39]. Nonaka and Takeuchi emphasize that an enabling condition for sustained innovation is, requisite variety, having a product team made of members with different backgrounds, perspectives and motivations. Requisite variety applies to cross-functional teams but also to team members with diverse life experience. Because it is through life experience that we acquire tacit knowledge.

T. Oshita, et. al. Bread Baking Machine. US Patent Office, 2004

(21) Matsushita Example of Tacit Knowledge

The classic example of the incorporation of tacit knowledge into a disruptive product design is the first Matsushita bread machine. It took a hands on experience of baking bread by one of the product engineers (a woman) to crack how to implement the mechanics of kneading dough in a bread maker.

(22) Team diversity and delivering value

Women are significant customers and influencers in the buying decision for software and software dependent technology. Statistically, women have different perceptions and preferences for software. Therefore, according to knowledge creation theory, it is a competitive advantage to have women individual contributors bring their tacit knowledge to software product development.


Next: Do Agile principles demand we confront the shortage of women developers…

Previous: Are women are under-served by software?

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.

Existential Joys of Agile Practice – Revisited

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.


Brocade Cloth1
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.

Vacuum Tubes2
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.

Daughter Watches Fireworks3
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.”

Extreme beyond this point4
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…

dandelion5

  • 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…

Broken Mirror6
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.

Worship the plan. The plan is good.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.

walk don't walk8
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.

Flower on Sidewalk9
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…

Darts Missing Board10
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.

Agile Lifecycle11
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.

Public School Door Knob12
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.

NYC Lego First Pits13
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.

Snow Storm Fort Greene14
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.

Sunset in Kona15
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.

yellow rope with knot by limonada16
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.

Angel17
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.

play at your own risk18
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.

Team19
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.

dandelion20
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.


This topic was inspired by Samuel Florman’s book, The Existential Pleasures of Engineering