Setting an Intention

This is what I said to open an all day creative exercise with our leadership team, and founder (Debbie) focused on our long term future…

The most important thing I have to say is Debbie and I have talked about this and we give you complete permission to let go of the day to day. We’ve given ourselves this one day out of 261 work days in a year to think about the future. Monday we can get back to the work of operating Stride.

As for today, I hope we make this a safe space. Your feelings are yours and you have a right to them. Your dreams are yours and you have a right to them. To borrow from open space. “The people who are here are the right people. Whatever happens today is the only thing that could.”

In terms of outcomes, today is an exercise in collective imagination. Everything we create here will be documented. We will share it with Striders. We will spend the next 3-6 months learning from them how to connect our plans to their aspirations. Ultimately I want every Strider to be able to use our vision to find more meaning in their day to day work.

This work is a piece along with our 2022 goals and the work you’re doing to mature our sales and consulting strategies. When we plan 2023 we will have the information we need to set meaningful and measurable long range goals and iterate on our corporate strategy.

Any questions on the outcomes or the day?

I want to talk about setting an intention. How much it guides our actions.

2035 is 14 years from now. 2007 is 14 years ago. In 2007, I was VP Eng at Oxygen Cable.

I’d been there eight years and we’d built a high performing Agile team: product, engineering and design. Our CEO had just started to work with us as product owner on a line of consumer software. She was looking to recapture her original mission to become a content brand for women.

Our first attempt was a kind of Pinterest two years before Pinterest. We were in beta and then over a weekend Oxygen was acquired. They new owner wanted the audience and carriage. But they didn’t want the mission.

It was pretty inevitable how things were going to play out. My team was scouted as individuals, each assigned separate transition responsibilities. I spent a decent amount of time writing down what I thought about the experience and laying out what I cared about.

About the acquisition process, I said:

We haven’t been rewarded or treated as one (team) but as individuals in service of organizations. A focus on citizens and cities – not neighborhoods.

What is difficult for the integrators to discern are the values, practices, spirit and reputation that allow this team to attract and develop new talent even as individuals move on.

About building software I wrote:

You can optimize construction practices as much as you want but if there is no discernible need for what you’re building…
The goal is not to build crap well. It is to find a way each day to do less and less crap and more and more not crap.

On professional ethics:

Ethical behavior is not about being right or infallible.

Human judgment is fallible but we must act to create the most benefit and least harm in accordance with the principle that others have as much right to joy, fulfillment and dignity as we do ourselves.

If harm results from even our best efforts we must take responsibility. No one is perfect and there are always mitigating circumstances but there are also no excuses.

Finally, I wrote this personal manifesto:

In my decisions and actions, I balance the following:

  • I care about the people who use what I create.
  • I care about the quality of what I create.
  • I care about the people with whom I create.
  • I honor my commitments to my employer.
  • I am loyal to people who have earned my loyalty.
  • I provide for my family.

I reflect on my decisions and actions to avoid:

  • negligence,
  • incompetence,
  • deception,
  • waste, and
  • harm.

Agile practice is a means to these ends.

Putting out what I cared about and what I wanted to create in the world influenced my actions and shaped my career. It became the filter with which I made decisions, informed what I learned and who I sought out to learn from. It guided my interactions with co-workers, what work I was willing to take, and with whom I built working relationships.

It’s why I met Debbie. It’s why I hired her prior company and then Stride. It’s why I joined Stride. It’s why I challenged fundamental assumptions about our business. And it’s why I’d chosen to work for someone who cared enough about Striders to listen to me and take a risk with all of us.

We have been handed the opportunity to make decisions with a broader frame of reference and longer timeline. And we can move more quickly because we have each other.

Even still, it can as long as it takes. Because the incremental steps are worth it and the journey is worth it. It’s worth it to live true to the vision, values and people you care about. To see a future that is better than the present and to work for it together.

Stride will evolve along with us. It will continue to attract inspiring people to work with us and rise to meet our aspirations to achieve our life goals, make a contribution to society, and help improve conditions on our planet.

Agile software development and “value”

Release BurndownAs advocates of agile software development we focus on practices.

The hype on those practices is they produce software, “faster, cheaper, better.” And we sell our efforts with the promise of, “delivering value.”

We speak of value as if the definition is shared, self-evident, contained within our backlogs and measured by our burn ups.

At the same time we minimize the hard and long the struggle to achieve mastery, identify and address a material need, and sustain creativity and quality.

So, we win the opportunity to labor with our teams to incrementally deliver potentially shippable units of code to stated business priorities.

When those priorities are pointless, so is the software.

When those priorities are tactical and subjective, the values behind agile practice — sustainable effort, maintainable code, self-directed teams, collaboration and trust — become irrelevant.

The truth is there are definitions of “value” that sell us out whether or not material success accrues to someone as a result of the software development effort.

And so, an agile adoption that is true to its participants is an ongoing, perhaps excruciatingly gradual, but substantive conversation with the larger organization on the definition of value.

A set of practices is only companion to the human values that give our work meaning.

Why solving ethical dilemmas is like building software

Here’s some grist for why we agilists can contribute to the conversation on software ethics and why it’s a fit topic for Agile 2009:

Handout notes I prepared for Agile 2008 drawing on the work of Jonathan Haidt and describing why ethical dilemmas have essential complexity per “No Silver Bullet.”

Agile 2008

toronto_skyline
Steven Doc List and I held a 20 minute presentation and 60 minute open space on software ethics.

I think the format works. Software ethics is not rules or reason, it is navigating essential complexity in building software and in moral choice. Descriptions that “abstract away its complexity often abstract away its essence” (Fred Brooks)

We embrace essential complexity using the values and practices of agile software development.

We can become better software developers using the same tools we use to build better software.

We can learn through practice to recognize and accept responsibility for the intended benefit and unintended harm we create.

We can retrospect on our actions and their consequences, engage in a conversation with our peers, learn from, challenge, and support each other.

Scrum Gathering – Agile and Ethics

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.