The five Core Scrum Values have been defined as:

  1. Commitment
  2. Openness
  3. Focus
  4. Respect
  5. Courage

The reference I’m using for this include a blog post by Mike Vizdos here. And you can see them articulated on the Scrum Alliance site here.

Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all his own. Here’s what Tobias had to say:

I believe there are some core values, that can help establish a way of being that offers a foundation for success in moving from a left-brain, logical, commanding culture, to a right-brain, intuitive, creative one. Each of these values begins within self, and can be lived independently of the reactions of others:

  1. Courage — seek your edge; speak from your heart
  2. Trust — lead from a place of faith, not suspicion; follow likewise
  3. Congruency — act with integrity, so your actions and your feelings are always in alignment
  4. Humility — acknowledge your uniqueness, celebrate your strengths, yet strive to be a worker amongst workers
  5. Service — Be alert to the needs of others; ask for and offer help in equal proportion, for service is in the receiving as much as in the giving

Through making a conscious, personal decision to live by these values, healthy community emerges. And when we have a healthy community we stand a chance.

I like the fact that Tobias takes a different view towards the values. His lens seems to be one that is more personally focused towards the agile practitioner or coach. So, I thought sharing the contrast would be helpful. But truly I want to focus in on the one common attribute in both lists—courage.

Focusing in on…Courage

I remember when I received my Scrum Master certification (CSM) in 2004 from Ken Schwaber. I’d been practicing Scrum for a while, since probably 2000-2001, and I wanted to gain some lessons from the “Father of Scrum”. So I flew to Chicago for a CSM class he was co-teaching.

I remember at the end of the first day, not being ‘wowed’ by the material and wisdom. I had truly not learned anything new and I was disappointed. I looked forward to the second day with anticipation—surely there would be something shared that was agile and wise and powerful.

At the end of the last day, the lessons were better than the first day, but I still felt disappointed. However, there was one breakout that was thoughtful, powerful, and made me think quite a bit.

It was a software project simulation about providing a ticketing system for Major League Baseball. The way it was written, Ken explained afterwards, was to articulate a Death March [i]project; one that should be politely but firmly declined because of the lack of feasibility.  However it turned out that very few class groups/attendees would ever actually say ‘No’ to the project. Instead, they would fall into a familiar pattern of problem solving, can-do behavior, and basically tell management what they wanted to hear: Yes, we can do this project.

One of the major points of the exercise was to test, what I’ll refer to as your courage, particularly if you were an aspiring Scrum Master. Did you have the courage to tell stakeholders the truth? Did you have the courage to steer your teams away from over-committing and underestimating? Did you have the courage to take a professional risk? Could you overcome our tendency to please our leaders and filter less? And finally, gulp, could you ultimately say “NO” to a project?

I followed the results of this exercise as it was given over and over again to early CSM classes. I remember Ken sharing that the failure rate, i.e. groups that would agree and commit to the project was around 96-98% of all attendees. The hope was for the groups and individuals to actually decline by this amount because of the way the scenario was written.

Put another way: You have a project that, due to the way it’s envisioned, constrained, and instantiated, inevitably will be a Death March. It will clearly fail. Yet, over 95% of the folks who review it want to sign-up and take a ‘whack’ at it. Imagine that!

When I think of this scenario, I refer to it as a Myers Briggs test of our inability to say no or challenge our leaders when given very, very challenging software projects. It seems to be in our DNA as technologists and employees.

So what are the aspects of “Courage” in software projects?

It’s hard to define courage because it’s so situational in the contexts I’m referring to. I’ll share some of the following aspects, knowing that the list is not exhaustive:

  1. Telling Truth – Say what’s on your mind more often. If a teammate is delivering poor software, tell them. If your boss is asking for more than your team is capable of without compromising quality, tell them. If you can’t meet some arbitrary date commitment, tell your customers so. Be bold, filter less, and tell more truth.
  2. Defending the Team – If you’re in a leadership position, instead of being responsible for strong-arming your team into saying yes, support and defend them. Be aware of their capability and push back when they are being asked to do more than is possible, feasible or wise. Be aware of technical teams’ tendencies to over-commit, so defend them from themselves as well.
  3. Know Thyself – Understand your strengths and weaknesses; leveraging your strengths and depending on your team to offset your weaknesses. Ask for help when you need it. If you don’t know how to do something, say: I don’t know. Then accept the advice and help of others. If you have a tendency to over-commit, realize it and ensure you have others who are more cautious and realistic around you.
  4. Be a Realist – At our heart, software folks are optimists and problem solvers. We love a good problem; the harder the better and we always think we can solve everything. It’s easy to say yes to everything or to take on all projects or to say you can do something you’ve never done before. It takes courage to tell truth and be more of a realist. Not every problem is solvable as presented to us and we need to realistically assess each “opportunity”.  Don’t be afraid to be the lone voice telling truth.
  5. Be willing to Walk Away – This is particularly true for leaders. You have to be willing to stand on your principles. If you get the inevitable management pressure to do something that you know won’t turn out well, you always have a choice. You can acquiesce to leadership and on your principles OR you can walk away. While it may be frightful, sometimes walking away is the most congruent, honest, and best response to a Death March project.

Wrapping Up

One of the common stories that came from students going through Ken’s scenario is that management threatens them. Some of them have been threatened with assignment to less than ideal projects and others with demotion to lesser roles. Still others have leaders who lose all subtlety and simply threaten to fire the team if they don’t take on the “opportunity”, ahem, I mean Death March.

Some of them also recount another strategy; one based on competition. Years ago IBM was notorious in starting two or three teams on the same project. They would let the teams “duke it out” to see who won. I guess it was nice to have so much cash on hand that you could take that approach. More recently, offshore teams are a competitive threat and, depending on the cultural dynamic, management will never see courage from them.

But no matter how you slice it, projects need to be setup for success and your leadership needs to listen to their teams. Have the courage to work hard, be cautiously optimistic, be a truth teller, and deliver great results. And if necessary, occasionally you might need to “vote with your feet”.

Stay agile my friends,

Bob.

[i] The term Death March was first articulate and described by Ed Yourdon in his similarly titled book. The book details the insidious dynamics of some software projects that are doomed from the start, but still manage to garner a sponsor who is unwilling to accept defeat.

Comment