Wednesday, 03 April 2013 08:54

The Agile Project Manager: Core Scrum Values & Courage

Written by
Rate this item
(6 votes)

Galen IMG01 April3The five Core Scrum Values have been defined as:

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

My references for this list include a blog post by Mike Vizdos, and the Scrum Alliance site where you can see them articulated.

Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all on 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

Galen IMG02 April3I 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 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”.

Thanks for listening,

Don't forget to leave your comments below.

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.

Read 7454 times
Robert Galen

Robert 'Bob' Galen is the President and Principal Consultant of RGCG, L.L.C. a Cary, NC based agile methods coaching & training consultancy. He is a deeply experienced agile coach who is active in the agile community and regularly writes & teaches on all topics related to the agile methods. Bob wrote the book Scrum Product Ownership, which is focused on that role and driving value in team delivery. Bob can be reached at and networked with via his LinkedIn profile.


0 # Curtis 2013-04-03 14:51
A truly amazing and insightful article, Bob. I'm on a Death March even as I write this. It was dumped on me as an ongoing problem and "NO" was not an option, else I lose my job. We have 90% of the work being done by an offshore team that, like you said, they never give any bad news, which ends up with a project that is going no where. I've worked harder at finding "my edge" but management seems determined to knock that edge off. This team has never hit a single date, for many reasons, but especially since they are in Asia and have no management close to them and their Scrum Master doesn't keep the team focused or proactively serve as an advocate to get them what they need to succeed.
This project really fits within that realm of Death Marches you describe, and should have been stopped long ago, but when this subject is mentioned to executives, the fear of financial penalties blinds them to the truth.
Reply | Reply with quote | Quote
0 # andreia silva 2013-04-04 04:02
great post, thanks for sharing
Reply | Reply with quote | Quote
0 # Keith Svetlik 2013-04-04 08:20
Bob, I plan to share this with my whole team. We can't fix what we won't face.
Reply | Reply with quote | Quote
0 # Marcos Ferrer 2013-04-06 12:22
In my opinion it takes courage to NOT practice these principles. Without these principles, projects are like crawling through tunnels that get narrower every month, with light vanishing, instead of appearing.

Well principled projects are like cruising the oceans for adventure - plenty of hardship, but new knowledge and excitement to compensate.

It comes from the top - the principles on any project usually reflect those from above - typically "Don't bother me", or "don't you want this job?".
Reply | Reply with quote | Quote
0 # Palaniappan 2013-04-08 02:42
Thanks for bringing us knowledge and clarity on how we can or what makes an agile project successful. If we address a few prerequisites like team acceptance, effective communication, and role clarity, agile project management would certainly bring good results. It's an article I would like to share with others. Thanks Bob
Reply | Reply with quote | Quote
0 # Jamal 2013-04-08 03:06
I think it all depends on the context in which the team is working. OPENNESS plays an important role in understanding the context. Suppose there is a situation where the management wants to garner an order from a prospect by showing an appealing demo to them. Management may ask development team to do many things knowing well that all of them are not feasible in the given time. On the face of it, a courageous development team may say NO to such a target. However, if they were also aware of the context and need of the hour, they would accept the task and try to finish as much as possible. Lack of openness on the part of management may make development team to say NO whereas in reality a YES would have been ideal!
Reply | Reply with quote | Quote
0 # Anand 2013-04-08 10:18
It takes courage to say NO to death march and still invite sudden death. Anyways, risks and rewards are part of any great leaders. I think it's better to say NO rather than your client holding you responsible for it after the fact.

Good article, Bob!!
Reply | Reply with quote | Quote
0 # DuVal 2013-04-10 18:39
In some instances the Death March can be historically or culturally organic. The greater team might be accustomed to working that way because that's the way it has always been done. It could simply be lack of awareness. One way to determine the health of an organization is to engage an independent, unbiased coach. (No, I'm not trying to sell anything!) Through observance a coach can evaluate the environment and then recommend areas for improvement - such as the common pitfalls Bob has outlined.
Reply | Reply with quote | Quote
0 # Allison 2013-04-20 19:16
Great breakdown of courage in software projects. Not too long ago the scrum master for one of the teams that I was coaching wasn't listening to her team, and it reflected a lack of courage by her and the management she was under -- I wrote a short blog post about it at Things have gotten better since, but courage doesn't come easily!
Reply | Reply with quote | Quote

Add comment

Security code

Search Articles

© 2016

DC canada 250