I’ll be presenting two talks at the November Scrum Gathering.

One of them is dear to my heart. I’ll be using this blog over the next few months to work up my ideas and document conversations I have around this topic.

The Ethics of Scrum and Agile Software Development.

Here’s what I proposed:

Presentation Description

Are Scrum and XP inherently ethical?

In the face of contradictory beliefs over what we do and how we do it, we software developers, agile or not, experience pressure to compromise our work and our due care for others. Meanwhile, as our products become more beneficial, more pervasive and inter-connected our potential to harm grows.

Attempts by the ACM and IEEE to engage us in a dialog on norms of conduct has resulted in a controversial code of ethics that borrows heavily from established engineering disciplines – mandating specifications to ensure effective software.

We, agile software developers are making an under-appreciated contribution to ethical practice in our field.

Whether our work is a profession or craft, we need to engage the larger community in a conversation about how our day to day actions affect our employers, our peers, and our society. This presentation will attempt to frame professional ethics in the context of agile values and practices.

Why is this topic of interest to Scrum Gathering attendees?

The discussion over norms of ethical conduct happens outside the earshot of most working developers. The day to day experience of Scrum practitioners is at a distance from those who concern themselves with software ethics.

As a Scrum community, we have a responsibility to help shape the expectations placed upon us by others. We cannot delegate our integrity. Nor can we defer concerns over negligence, recklessness, or intent to harm the human beings who use the systems we create. We openly discuss our projects, our working conditions, and our advancement but to protect those very interests we often deal with issues of conscience privately.

Yet the passion behind Scrum is, in part, an idealistic one – a hope that by dealing openly and responsively with our stakeholders we will build something of real value. We need to harness this idealism to encourage each other make better decisions in the interests of stakeholders who do not pay us and do not always have a seat at the project table.

Given the downstream effect ethical lapses large and small have on society, we need to engage in this discussion or have the wrong solutions imposed upon us by employers, institutions, and regulatory agencies.

Presentation Objectives

1. Is it important for us to establish a shared commitment to ethical conduct?
2. What obligations a software developer should feel beyond fulfilling the requirements of their employer?
3. How the Agile Manifesto and Scrum/XP practices suggest a partial set of norms of ethical conduct.
4. How agile organizations have started to provide their own statements of principles to extend agile values and encompass conduct towards our peers and society.

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

Tag(s): agile, ethics, scrum, software developer, software developers, software ethics, wrong solutions, xp

Comments: none

I’ve posted about why I need to encourage agile practices outside my department.

If Scrum is isolated within one team, its very success can be used to counter further adoption. “Agile works for you but what we do is different. You do X we do Y.”

This resistance is a direct result of what Andy Hargreaves calls balkanization — groups insulated from each other, with hard boundaries, loyalties and a political complexion.

Creating a culture where groups work together to improve the organization is core to lean and agile. So the best ways to counter balkanization are the very principles under challenge.

I’m tackling this top-down by lobbying senior executives to bring in an agile/lean coach, bottom-up by removing impediments for my team, and, perhaps most significantly, sideways by initiating a Scrum in another department.

I have tentative approval from another department’s senior managers. Now, I have to meet with line managers and identify a backlog of work. Then solicit volunteers for a team.

I’ve taken Ken Schwaber‘s words to heart and asked them to Scrum their hardest challenge or the work they think least suited to agile.

So many things can go wrong. Of course, nothing that isn’t already going wrong. That’s the point.

Scrum will highlight those problems and make solving them obvious and necessary if no easier.

More to come…

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

Tag(s): agile, agile/lean coach, Andy Hargreaves, Ken Schwaber, management, scrum

Comments: none

I’m half-Japanese but my wife introduced me to Anpanman by Takashi (嵩) Yanase (柳瀬).

I can’t give any better description than the Japanese Media Communication website:

“Anpanman will go anywhere to help anyone in trouble, to drive away villains, and to save people from starvation by allowing them to eat his face.”

“Anpanman is the hero of the new age, glowing with friendship, endeavor and justice.”

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

Tag(s): management, scrum, starvation, Takashi (嵩) Yanase

Comments: 1

It’s a privilege to be granted authority in another person’s company.

It’s easy to criticize. It’s hard to raise capital and make payroll.

I have never been an entrepreneur. My passion is to build teams. To be of service. To make things better.

I’m that second generation that feeds off founding vision and hopes to sustain an organization.

This has been a good week.

• We achieved our first business objective on our standard bearing product initiative, Ript™.
• My CEO is championing agile values in my division’s executive team – accountability to specific commitments within a time box.
• Managers in a peer group recognize the potential of self-directed, cross-functional teams and are interested in introducing the first scrum outside my department.

I am a cautious optimist. Success is far from inevitable. Actually, all this represents is an opportunity to start the really hard work.

Still some moments, especially ones years in the making, need to be savored.

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

Tag(s): agile, CEO, entrepreneur, management, scrum

Comments: none

I laughed out loud when I saw Ken Schwaber titled a passage of his book, The Enterprise and Scrum, “Just Do It”.

Ken describes how a customer can sacrifice quality and sustainable pace in the short term but pay it back at a premium, “$4 to remediate every $1 drop in quality.”

Clearly there are pressing bugs, misses and serendipitous opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a sprint.

But when you manage a self-directed team, “just do it” — and I’ve heard that very phrase — is bullshit.

Just characterizes another person’s work as easy. It is the people performing work that need to estimate it. They are on the hook to execute and are incented to think critically in detail about what they are taking on. The worker grasps the actual effort better than the executive.

Do characterizes the work as physical action. Software development is problem solving and abstract modeling, i.e. knowledge work. “I’m typing as fast as I can?!” Even industrial lean practice relies on workers engaging beyond the boundaries of the immediate task to improve the product and the process of manufacture.

It characterizes the work as a single, clearly defined task. Again, the person doing the work determines whether they clearly understand assignment. Otherwise, you’re not admitting to any ambiguity of language, hidden complexity, or potential misunderstandings.

Just do it is a one way directive that splits responsibility from authority, i.e. YOU just do it. It signals a leader is not willing to do their part to remove obstacles for their team.

Just do it hides inefficiency under a veneer of necessity. Is it a surprise that “just do it” finds companionship with “just the way things are done” and “just the nature of the business”?

All this to say “just do it” in knowledge work is bullshit. The value lies not in the truth or falsity of the statement but the effect it has on the hearer. It dismisses workers’ concerns and excuses management from accountability.

Moving from bulls to birds, if self-directed teams are the goose that lays golden eggs, “just do it” is a pellet blast in the ole’ egg layer.

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

Tag(s): agile, Executive, Ken Schwaber, management, scrum, software development, USD

Comments: 4