Scrum Teams vs.Online Team Gaming Mechanics

In a great blog post from Coding Epiphany from 2015, cross functional Scrum Teams were compared to RPG parties, mainly focused team makeup, skill specialization versus crossing roles and forming a team as you go.  It’s awesome and nerdy.  I had a similar idea, but instead of that comparison, I wanted to compare a Scrum Team to Team Mechanics from online gaming, mainly MMORPG or maybe some team based shooters. Continue reading


The Case for Dedicated Scrum Masters

“All our Scrum Master, Bob, does is sit around all sprint. I mean, he’s there for our Daily Scrums, and Sprint Planning. He goes to our Sprint Review and watches the stakeholders, and he asks a lot of questions in our Retrospectives, but what does he do the rest of the time? It’s not like he’s writing code…”

Have you heard something similar to that before? Maybe even said it yourself?  It’s a pretty common refrain, and one of the driving forces behind the idea that we can have part time Scrum Masters, and still be as effective as we think we should be.  Continue reading

Where Should We Go For Dinner? Decision Making and the Fear of Rejection


We are all faced with decisions to make every day. Paper or plastic, regular or decaf, what’s for dinner… so many choices. When we’re alone, we take into account our own feelings, bias and knowledge, and usually come up with some kind of action or response, often because we have to or that guy who really needs a coffee is right behind you.  However, once you start adding other people to the decision making process, things start to get muddy. Take, for example, the classic dinner conversation:

Person A: What do you want to get to eat?

Person B: I don’t care, whatever you want is fine.

A: I dunno, either, that’s why I asked you. Well, what about Pizza?

B: Nah, I don’t feel like having pizza.

A: Oh… OK. Well what do you feel like?

B: I dunno, you pick.

I’m sure just about everyone has been on one side or the other of that conversation.  The thing is, this conversation happens all the time in every group of people. Observe:

Teammate 1: I propose we spend an extra hour each week doing research on new methods of data access.

Teammate 2: I’ll go with whatever the team says.

Teammate 3: Doesn’t matter to me.

Teammate 4: I agree with 2.

Teammate 5: <Crickets chirp>

And so on and so on…

So what happens here? Well, either the team goes with the suggestion, based on one person’s input, or no one feels strongly enough about something, so the question lingers. Let’s look at what can happen in these cases:

  • The team goes with the suggestion, and they like it: The team will be more willing to go with the suggestions of Teammate 1 without thinking critically about it. The team has given up ownership and self-organization to one member. Teammate 1 may feel the burden of being “the guy/gal with the ideas”, and stress over needing to come up with all the plans.
  • The team goes with the suggestion, and it fails: The team can engage in finger pointing at Teammate 1, after all it was his/her idea, and I never said I actually agreed. Teammate 1 feels called out, leading to rifts in the team, or causing him/her to withhold new ideas from the team, even if they’re good. Other members of the team see how Teammate 1 was treated, and are now wary of putting their ideas out there.
  • Lacking motivation, the team maintains the status quo: If there was a potential issue, it continues unaddressed. Teammate 1 is left in limbo, unsure whether to push forward with his/her idea, or to drop it. Teammate 1 feels disrespected, since no one was willing to consider his/her idea long enough to form an opinion. All teammates recognize group apathy, and choose not to share new ideas.

For Agile teams who want to be high-functioning, this is a major problem. There is a lot of psychology behind why, as humans, we prefer not to make decisions. You can find that on the web, so I’m not going to go into that here.  In my experience, however there is one major force in play:


People fear giving their opinion.  By giving an opinion, you open yourself to rejection. You open yourself to conflict. You open yourself to looking weak because you are ill informed. And you open yourself to the worst thing ever: the possibility of being wrong. Nobody wants to be wrong. When you are wrong, it’s even harder to admit it. Sure there are other possible reasons, like a lack of respect for the questioner (so much so that you can’t be bothered to have an opinion), or being too distracted to answer fully (generally better to state as such), but generally when faced with a normal decision to be made, if we choose not to give our opinion, it is out of fear.

People feel like by saying “I’ll go with the team” they’re providing tacit approval to ideas their teammates come up with.  In reality, all they’re doing is passing the buck and hoping someone else will do the thinking for them.  It’s a disservice to the the both the person asking, and the person answering.

So what do you do if you really don’t have an opinion? Well, communicate and negotiate. For example, “I don’t really understand what an extra hour of research will do for us. What do you think we have to gain from this?” Once you understand the question, do your teammate the service of giving your honest opinion.  If you disagree, have an open and honest conversation as to why. If you really agree, give a firm agreement, and stand behind your statement.  Nothing is gained by delaying conflict if it needs to happen, and much can be lost if feelings are hurt.

The best thing? You can apply this anywhere! Let’s look at the ideal way of handling the “Dinner Problem”.

Person A: What do you want to do for dinner?

Person B: I hadn’t really thought about it, do you have any suggestions? What do you feel like having?

A: I don’t really want anything fancy, quick and easy for me. What about you?

B: I’m still not really sure what I feel like having, can we go somewhere with a lot of choices?

A: Quick, easy and lots of choices? You know, there’s that food truck night at the local school tonight, why don’t we go there?

B: OK, I can agree with that. Sounds like an adventure!

Well, that seemed a bit too easy, maybe we can dream about that last one…

The Agile Master

Catchy? No, I’m not proclaiming myself a master at Agile… actually I wanted to pose a question. In Scrum, there is a role called the “Scrum Master”. It’s very unique, and it speaks to what that person is all about. They will (in a manner of speaking) master the Scrum. Not the Scrum Team, but the Scrum itself. They facilitate, lead, coach, and in general do what needs to be done to facilitate the Scrum for their team, so that the team can focus on delivering value.

However, once you get outside of Scrum, does that person disappear? Just because you’re running some other Agile flavor like Crystal or Lean Software Development (maybe supplemented using Kanban to control work-in-progress) on a DevOps team, does the need for a “Scrum Master”-like person disappear? The most common title I’ve seen is the “Agile Coach”, which is a great title as well. One of my favorite books (indeed, my coaching bible) is Lyssa Adkins’ Coaching Agile Teams which uses Agile Coach as the title of this role. However to me, “Agile Coach” can be both too narrow and too broad of a description or role. If only interacting with a team, this person does far more than coach. Like the Scrum Master above, this person will not only coach and teach, but facilitate, remove impediments, resolve conflicts, and solve problems. On the other hand, I’ve seen Agile Coach thought of and described as a coach/mentor for a group of “Scrum Master” like people, be they actual Scrum Masters on Scrum teams, or other such facilitators.

There is a distinct difference which seems to go unaddressed. Scrum Alliance makes a distinction between the Scrum Master/Scrum Professional level and Scrum Coach/Scrum Trainer level of certifications. does not, but they do make a distinction for experts which they list on their site.  Agile as a discipline at large does not seem to do so. Scrum Master sounds focused, Agile Coach is kinda nebulous, and doesn’t speak to your team’s discipline.

Maybe we can just add “Master” to the flavor of agile your team most closely resembles? That sounds fun!

  • The XP Master! World of Warcraft here I come! Or, a Windows guru from last decade.
  • The Lean Master! I can lean at any angle! 30 degrees, 32 degrees, you name it! (OK I know it’s supposed to be bend, bite my shiny, metal… ahem.)
  • The Crystal Master! New age hippy, or reject boss from the Legend of Zelda series?
  • The Agile Master! I don’t know, sounds like it outranks a mere Coach…

At the end of the day, it doesn’t really amount to much, mostly semantics and curiosity. As with many things, I don’t know the answer, I just pose the questions.  What do you think? Leave me some comments!

Introduction: The Zan-gile Blog

Hello, and welcome to my brand new, fresh out of the box, Agile blog: the Zan-gile Methodology!  I know, I know, clever name, right? I’m sure you’re wondering “Zan, why are YOU making an Agile blog? Aren’t there like, approximately, 37 million Agile blogs out there? What can you offer?” And I say, “Read on, hypothetical reader, let’s talk about it!”

Let’s start right away and say I’m not here to bring about big, sweeping changes in the world of Agile. That would be foolish for many reasons, not the least of which being that I believe incremental changes are generally a better idea.  So don’t let the title fool you. I haven’t come up with some silver bullet, magical one-size-fits-all solution. I am simply a huge fan of the Agile Methodology, and I look to live it and love it every day.

“We are like dwarfs sitting on the shoulders of giants. We see more, and things that are more distant, than they did, not because our sight is superior or because we are taller than they, but because they raise us up, and by their great stature add to ours.”

Along my Agile journey, one of my biggest sources of inspiration and knowledge have been blogs. Some were written by huge names in the Agile world, such as Alistair Cockburn, Martin Fowler and Mike Cohn, and some were much smaller such as micro-blogs posted on the Scrum Alliance website, LinkedIn and their ilk, and many more in between. Many I have learned from, some I have disagreed with, but all helped me form myself into the ScrumMaster and Agile Coach I am today, and will continue to grow to be.

This blog may serve as no more than a place for me to collect my thoughts and organize them so that I may refer back to them to see how far I have come. If that is the case, I am content. However, if I can deliver value in such a way that even one person may read my blog and come away with new knowledge, a fresh perspective or even a hunger to research to disprove my opinions, then I will be both infinitely humbled and extremely gratified.

So with that I say. thank you for taking the time to read my thoughts. I crave your feedback, so make some comments!  Look for more content soon!