In response to “Doc” and my proposal for an open space on dilemmas agilists face in the workplace, we’ve been asked what the ethical issues are around Agile and whether the topic is worth the three hours we’ve requested.
Agile is built upon a set of values. They are normative in that they declare certain behaviors and outcomes as better than others. They hint at a vision of who we ought to be and what we ought to be concerned about.
As we quoted before, Jim Highsmith believes agile is engaged with the “mushy stuff of values and culture”. At Agile 2008, Bob Martin declared agile to be no less than a rallying cry to free developers.
As we strive to embody agile values in the world we will encounter dilemmas — tough, ambiguous decisions fraught with fears, limitations, risk, possible sacrifice and consequence to others.
As illustrated by the Scrum MLB simulation many of us have participated in, an intellectual understanding of agile practices doesn’t protect us from saying what people want to hear in order to get work, avoid conflict, or out of an earnest if self-defeating desire to please. Even in circumstances which offer no material stakes.
It’s more than falling short of ideals though, it is about how we fail to seriously consider these values in the first place — the hard shell of justifications for doing what we are told. I’m personally alarmed by the lack of reflection I see practitioners who take holding a job to mean we can proceed without consideration for co-workers , end users, and society — stakeholders who don’t pay our salaries.
Agilists are uniquely suited to contribute to emerging software ethical norms now largely defined by academics and waterfall practitioners (I say this non-pejoratively). We aren’t trying to refine human frailty out of the equation. We embrace essential complexity. We have techniques for reflection and continuous improvement. We turn community into our greatest strength.
But there is a conversation to be had about whether the stated agile values are enough. They don’t really speak to our obligations to our peers and our society.
Should we hold each other to higher standards? Can we challenge experienced practitioners to contribute to the field, create good will, mentor, and do good works? Should we abide self-proclaimed agilists who show no talent for initiative, courage, honesty, collaboration and love of team? Doesn’t their work reflect on us? Particularly since the growing demand for agile which they exploit is built upon the hard work of our peers and mentors?
Don’t we owe some responsibility to the reputation of our practice, the long term viability of our careers and our industry — in the interests of making software which benefits people more and harms people less — to demand more of each other?
This isn’t idealism, this is the demand society will make of us as our numbers grow and our works affect people’s daily quality of life. The pervasiveness and interconnectivity of technology and the growing dependency of ordinary people on software services is creating much greater potential for the average coder to create benefit and to unintentionally harm. There are historical precedents in fields of engineering, science, letters, and the arts where codes of conduct become hardened into enforced standards and even governmental regulation in reaction to some controversy or catastrophic failure.
Finally, we need a way to confide in each other about the actual dilemmas we face in the workplace. There are few safe spaces for community and peer coaching through the intolerable conditions some of us face. Whether it’s abuse, dishonesty, or some other harmful behavior by peers or the people who have power over us. I worked in a place (briefly and I do not list this place in my resume) where a pregnant developer quite two weeks into the job for fear of the health of her unborn child. Isolated and afraid for our livelihoods, this is a terrible time to be compelled by circumstances to do things that compromise our integrity or to sit silently while others face harm.
These are not conversations that should “presented”. This would be sanctimonious and unhelpful. Rather we need to consider these topics with humility as peers.
An open space lends itself to this. I’ll let Doc describe open space technology in more detail but it is a self-organizing process. You gather, give yourself the luxury of time and space to think and to discuss a pressing concern on your own terms with the people who choose to join you. The sessions flow and change as new topics arise and old ones wind down. Then the whole comes together to pull the experience into a coherent conclusion. The process is self-documenting with proceedings of the event created as you go, then collated and provided back to the attendees. All of this takes time. Whether the time is worth it is a matter for the participants themselves to decide.
I hope this helps explain my motivations for co-proposing this session. More feedback is greatly appreciated.
Posted: March 7th, 2009 under software development.
Comments: none
You can optimize your construction practices as much as you want but if there is no discernible need for what you’re building… 
, by Andy Hargreaves & Michael Fullan. 
Executive manager, software developer, father and husband trying to do more good than harm.
