Time to shift focus: from Scrum tools and process to practice

I am ambivalent about the Scrum community’s focus on process and tools.

Yes, it is this effort that has driven adoption and created an economy for us practitioners. But adoption is yesterday’s challenge. We’re kind of winning that one.

We need to place less emphasis on getting new organizations to try Scrum to more on getting existing teams practice Scrum better.

DSCN1768.jpgHow many of us many, many Scrum adopters strive towards the potential of the practice?

  • Where reliable software delivers monetary return to sponsors because it is truly valuable to end users.
  • Where individual contributors are allowed to bring their most creative effort to the workplace to the benefit of both employers and end users.
  • Where workers are allowed to live rewarding lives outside the workplace to the betterment of their families and communities.

Not just exceptional productivity – ambitious enough as that is — but exceptional productivity to a genuinely productive end.

Life is full of compromise but if that is not the aspiration — to fill our careers with as much of these achievements as possible — then why bother?

Why spend money on training and tools to deliver more waste on short, iterative cycles?

Why extract more lines of code that no one will test or use but only spend money to maintain?

Why use the Scrum process to perpetuate the alienation of the knowledge worker from their work?

Mastery means taking responsibility for ourselves and our peers. Grasping our practice is the sum of our intentions and actions in the service of something.

So here’s my plea to shift the conversation back to it’s roots.

“Agile” is about the material and human good we create when we respect our co-workers tell truth to our employers, strive to improve, and care for the people affected by the software we help build.

We use a tool or process to the degree it furthers that end and no farther.

Oops… learning lessons over and over

Here are agile software development mistakes that kick my ass whenever I let them:

  • Know the assumptions in plans. Recognize when they change.
  • Don’t abuse time boxing. It is a toe hold for over-committing. When the time box ends, the work ends.
  • Doing Scrum means DOING SCRUM. Sloppy backlog. No Scrum. No Product Owner. No Scrum.
  • No iteration boundaries and no commitment doesn’t make me “lean”.

Demanding more of each other – Agile, Ethics, and Harm

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.

The next big thing

The hot topic in the scrum community is scale.

Size may offer more opportunity (it may not) but it demands overhead and compromise.

Necessity forces us to skip to advanced topics but there are so many fundamentals to master:

  • recruiting and developing talented and diverse individuals,
  • forming collaborative and highly productive teams,
  • crafting ambitious work at sustainable pace,
  • excellence, invention, and joy that benefits ourselves, our peers, our customers, and end users.

I’m not as interested in learning how to work with more people as I am in learning how to invent valuable software really, really well.

Catastrophic mistakes

Untitled by LucKyL - WahoO from flickrConstrux has a white paper revisiting Stephen McConnell’s Software Development’s Classic Mistakes.

In it, they list ten mistakes most likely to produce catastrophic or serious consequences.

Half of them speak more to executive and product management than development:

  • #1 unrealistic expectations
  • #2 weak personnel
  • #4 wishful thinking
  • #7 lack of sponsorship
  • #10 lack of user involvement

Given my experience of organizations that means projects are marked for failure well before agile methods are even applied.

Under these circumstances, we can hope frequent delivery will either morph the project into something more valuable or cause it to die a quick and merciful death.

A better answer disperses transparency, collaboration and continuous improvement from the team room out to sponsors, stakeholders, support units, suppliers, customers and end users — from development and project management to economies.