Tag Archives: principle

Setting an Intention

Posted on by

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.

Dear agile consultant – hiring criteria for coaches and mentors

Posted on by

play at your own riskDear consultant who uses “agile” as part of your brand,

I am a possible customer who embraces agile principles, practices agile techniques and has done so for years.

I admire the tenacity and talent it takes to build a business in consulting.

The best of you offer your clients techniques, language and a way of thinking that can better lives and turn around companies: advising them in ways to change their own organizations, bolstering their courage to experiment, helping them learn to iteratively learn, inspiring them to foster teams, empower individual contributors, incrementally improve, and helping them grow past dependency on your services.

Here’s how I judge whether a thought leader is a worthy mentor:

  • Your reputation among those of your peers I know and respect.
  • Do you provide context/share credit: “This is where it originated, this is who popularized or researched it, this is who’s written well on it. This is my version of it.”
  • Do you espouse principles: “This is about defining work that builds equity because it offers real benefit to end users and a way of working that entrusts individual contributors of diverse talents to collaborate within teams to deliver that benefit.”
  • Are you frank: “Most companies who try this fail. Most managers who try this will not change their own behavior enough to allow their teams to succeed for them.”
  • Do you embody the principles: “It is about your team(s). Not me. I do not have right answers only experience, a willingness to listen, and techniques to help us figure out what you need to do to help yourselves.”

Conversely, these are the bad smells:

  • Celebrating the widespread adoption of “Agile” without acknowledging most “agile” adoptions are crap.
  • Celebrating scale not individual team excellence.
  • Focusing on techniques not principles as if “stories” and “iterations” were magic.
  • Talking about software tools before disciplined engineering practice.
  • Talking about “value” and “productivity” as if a leader’s understanding of these terms were not a/the major obstacle to their workers ability to perform.
  • Jamming agile practices into a contradictory way of thinking: “Agile process manager” anyone?
  • Coining new jargon for a slight spin on existing practices: It looks like a timebox, smells like a timebox, tastes like a timebox. “I call it creato-inno-rations™.”
  • Putting yourself above the problem: Just because you were really good when you practiced doesn’t mean you are a brilliant coach. Just because you’re a brilliant coach doesn’t mean you can do my job better than me. Just because you can do my job better than me doesn’t mean paying you to not do my job provides my company value.
  • Overheated claims of personal invention/Not giving credit to others. Sorry guys (and I mean guys), Mary Poppendieck was talking kanban and software development fifteen years ago. You’ve advanced the craft, you’re changing minds, and you may be very good at what you do but you are not Archimedes.

As a potential customer, I need your honest criticism, I am impressed by your ability to learn from others. I respect determination and humility more than bravado.

Give credit where credit is due and do exceptionally well.

Working on a paper about women in software development

Posted on by

dandelionI just submitted a paper on agile values and the underrepresentation of women in software development.

This is not an original topic but the research I’ve read has focused on how women who participate in agile practices, particularly XP pair programming have more favorable impressions of the work and of their ability to contribute both of which are correlated to entering the occupation.1,2

My belief is that agile practices are tools but it is the agile values that give us the urgency, courage and insight to wield those tools towards a desired outcome.

That is, we are much more capable of making software development more tolerant and inviting of diversity if we believe we should do this as part of our core mission as Agilists to develop with craft and quality and to deliver value to our employers and our end users (do not forget).

So, the rough outline of my paper is this:

  • The shortage of women entering software development and disproportionate share of women leaving mid-career is real and measurable and well documented.
  • The problem is worse in IT than it is in almost all other areas of STEM because, unusually, the percentage of women in software development has actually declined over the last 20 years.
  • This shortage and particularly the attrition of experienced women developers represents a material burden to our industry.
  • Product teams that represent the diversity of their customers have a potential advantage in developing products that appeal to that diverse customer base
  • Women are at least the equals of men when it comes to influencing consumer technology spending and online activity
  • Therefore, it is in the interest of the industry to educate, recruit and retain women developers
  • Agile is a collection of practices united by a coherent set of principles
  • As agile becomes mainstream it is more important than ever that practitioners understand and embody these principles
  • The creators of the Agile Manifesto realize this and are calling us to a principled approach to our work
  • These principles are at stake when it comes to things that affect the competitiveness, insight into end users, and potential for innovation in our teams
  • If we engage our agile practices behind this principled cause we can begin to remove the impediments within our own organizations to the recruitment and retention of women
  • When we do, we will influence larger changes across the industry, within education and in society

I’ll go into more detail and try to defend my arguments in later posts. In the meantime, I’m happy to engage with anyone who finds fault in my premise.


1S. Berenson and K. Slaten. “Voices of women in a software engineering course” in JERIC, vol. 4.1, Mar. 2004.

2O. Hazzan and Y. Dubinsky. “Empower Gender Diversity with Agile Software Development” in Encyclopedia of Gender and Information Technology. E. Taugh, Ed. Hershey, PA: IGI-Global, 2006, pp 249-256.

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

Posted on by

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.