The Story of Why I Left Riot Games

Image courtesy of Vladimir Gitlevich

“So this is it. This is going to be the thing.”

That’s what I remember thinking as I left the room where I had just finished a conversation with two female mentees.

I had wondered for some time when there would be an incident serious enough that I had to talk to leadership about unacceptable behavior in the workplace, and here it was.

The Issue

At that point, I had been at Riot Games for a year. I loved my job there. Few companies have embraced what I do in the way Riot Games did. In the first six months, I had significantly reworked our approach to Agile development processes. I was told that leadership referred to me as the “Weapon of Mass Production.” (I must confess still being very fond of that moniker.) In early 2013 I was asked to establish the Product Management discipline, reporting directly to Riot President and Co-founder Marc Merrill. I worked with so many amazing and talented people there, and investing in their lives was deeply fulfilling to me.

However, the frequency and intensity of inappropriate behavior in the workplace had become a concern not long after I arrived. There were two predominant flavors of behavior. One was the use of sexual references and gestures by straight men toward other straight men, and the other was the sexist and inappropriate language about women. At that time, Riot was still a very young company made up of mostly very young people. I told myself that perhaps part of my calling in being at Riot at that point in time was to model more appropriate behavior and language and usher them into that next phase of maturity.

So, when people would say things to the group like “the other team raped us because our mid kept jungling,” I would attempt to reflect back more appropriate language by saying back to them “so you’re saying your team lost because you weren’t working together.” I can’t say that I think it had much impact, but I figured this was the long game, and slow and steady would win the race. Cultural change requires perseverance and consistency over a prolonged period of time, right?

The sexual references by straight men directly towards other straight men were a more complicated issue. It would often be homosexual in nature, but could also be sexually aggressive toward your significant other. You might be talking to a leader about conflict with a peer, and they’d respond with “man, you’re acting like he had sex with your wife.” Or they might start a paragraph by saying “Now for instance, if I fucked your wife…” and then segue into what they were actually supposed to be saying. The homosexual variants would be things like “well if he sucked your dick, would you feel better about this?” or “it’s not like I’m asking you to suck my dick, but I’d be OK with it if you did.”

This behavior of male-on-male aggression seemed to be a mechanism of asserting control. If you got rattled by it or responded angrily, you were seen as immature or insecure, and how could such a person be an effective Rioter, especially in a leadership role? So, the way a number of men coped with it was to not respond, and not appear provoked. Sadly, a very common coping mechanism that many men chose was to begin to exhibit the aggressive behavior themselves, often with greater intensity than they had seen it modeled. The net effect was that disagreement with the behavior was silenced, emulation of the behavior made it more prevalent, and the overall environment became fertile ground for sexism toward both men and women to run unchecked.

My personal preference was to respond with clarifying language while addressing them by their first name, and convey “can we just get through the conversation we need to have” non-verbally with my facial expressions and gestures. My hope in doing that was to communicate “what you are doing has no power over me, makes me think less of you, and now I am having to speak to you like an exasperated camp counselor.” The aggressive behavior was constant, often daily, and the need to counteract it really wore on me, though I think the drain I experienced as a straight white male was nothing compared to what others at Riot endured.

The Event

In late Spring of 2013, Nancy Hilpert had come in to lead Recruiting. She announced at one leadership meeting that Recruiting would be shutting down for 50 days in order to restructure and reboot itself. That reboot culminated in a full-day offsite held on a Friday. Approximately 160 people, all the hiring managers at Riot at the time, were brought together to learn about our new and revitalized approach to Talent Acquisition.

The Friday kicked off with an AMA with Brandon Beck and Marc Merrill, where they shared stories about how taking Talent Acquisition seriously since the early days had been key to Riot’s success. (For those who haven’t heard the term before, AMA stands for “ask me anything”, and it refers to a loosely-structured type of interview popularized by Reddit.) The two shared some great stories about candidates they pursued who were critical to getting League of Legends shipped in those first harrowing months of launching. Then they shared an example of how one candidate did not take an offer initially, but because we persevered and followed up, they eventually did take our offer. At the end of that example, Brandon laughed and said, “I was about to say something.” He paused, and then went on to say, “No doesn’t necessarily mean no.”

The next five to eight seconds seemed like minutes. The hall we were in was about three times wider than it was deep, and I was seated just right of center toward the front. Pockets of raucous laughter broke out distributed about the room among lots of silence. I looked to my left and locked eyes with my original hiring manager, and we shared a one-second look of “Did this just happen?” The AMA continued for a bit, and then we went into a day full of workshops. I told myself that it was probably just a misstep, because there was no way Brandon would purposely use rape as an analogy for persistence in recruiting, and it would just fade into the background.

However, at the end of the day, Nancy got up to give a recap with a slide deck. And there, in the recap, she had a slide with “no doesn’t necessarily mean no” on it, and she’s reiterating it as a slogan of sorts. At this point I am concerned, and also anxious. “I think I am going to have to say something. God, I don’t want to have to do this.” We dismissed and went to a happy hour in the hotel, and the offsite ended. That weekend, I debated whether this merited bringing the issue to leadership. Was it that bad? I mean, it was bad, but was it bad enough for me to put myself at risk by saying something?

Back at Riot headquarters the following Monday, the Recruiting team held an onsite event where some of the offsite event resources and guidance were shared with all of Riot, since the offsite was just for hiring managers.

The next day, one of my former direct reports and her direct report, both of whom I was actively mentoring, asked to speak with me as soon as I could. We met up right away, and they were visibly upset. One of them said to me, “There’s a rape joke in some of the recruiting material, and they’re saying it’s something that Brandon said at the offsite. Is that true? Did he say that?”

I think I took a deep breath, followed by a long sigh. It was a simple question, with a simple answer, but with that answer came grave implications.

“Yeah, he did.”

Seeing their hurt and concern, I felt mad at myself for not having said anything yet. I knew it was not OK, I knew it would have this effect, and I had delayed saying anything. My “thinking it over” was really me wavering on whether I would do what I knew was right, because I feared the repercussions. “I’m going to say something to Brandon, I just need to figure out how to say it.” We got up, and quietly shuffled out the door.

“So this is it. This is going to be the thing.”

The Email

The morning of August 1st, 2013 I received a call from my mother to inform me that the youngest of my aunts died unexpectedly. She was only 8 years older than me, so she was more like a big sister or cousin. It was a bit of a blow.

I was about to travel cross-country for the funeral, and the company-wide trip to the Dominican Republic was coming up in a week. Back then, getting on Marc or Brandon’s calendar for 30 minutes could easily take two weeks. If I didn’t do something soon, this would be delayed for weeks.

The next day, I crafted as diplomatic an email to Brandon as I could muster. I wrote that I doubt he meant it that way, but that people took the “no doesn’t necessarily mean no” as a rape joke, and how it really became a problem once Nancy baked it into the material. I went on to say that I knew we didn’t want to convey that message, and was happy to talk about it if he wanted.

I will never forget changing planes in San Francisco the following Monday. I pulled out my phone to check email, and found replies to the email I sent Brandon, but not only him. My original email had apparently become a thread with some folks in leadership. I recall it mentioning that hyper-sensitive people who didn’t understand intent were a problem we needed to address at Riot. I closed that email thread, and immediately below it there was a meeting invite titled “Riot Voice and Sense of Humor” set for when everyone returned from the company trip. The invite included the co-founders Marc (my boss) and Brandon, the head of Communications, the head of Legal, and myself.

The Meetings

The meeting began with me being asked to tell everyone what I think happened. I said something like, “the day began, the AMA happened, Brandon said the ‘no doesn’t necessarily mean no’ thing, we had the rest of the day, Nancy put that in the deck, and we all went to Happy Hour.”

At some point I think I referred to the slogan as a rape joke. Brandon pulled up a picture of a t-shirt that had an iceberg floating in water on it with the words “just the tip”, and said he had that t-shirt, and what did I think of it. I said I didn’t think it was appropriate. This led to a bit of back and forth between Marc, Brandon, and I, followed by Brandon talking for several minutes. I think Brandon felt misunderstood and misinterpreted, and that my email implied that I thought he condoned rape. After he had talked for several minutes, Marc said, “So what do you think about what he said?” I replied, “I think he thinks these sorts of things are OK and I don’t.”

That led to more of Brandon talking about not supporting rape, and also about our culture and having a sense of humor. After he had talked for a good long while, Marc again asked what I thought about what Brandon had said. I answered that as a white male I thought they had gotten all the insight they could get from me, and if they wanted more, they should ask the women who were there. I recall that not going over well.

Brandon again spoke for a long while, and Marc again asked what I thought. At this point, a pattern was emerging. Brandon would speak, Marc would ask what I thought, and I would respond in disagreement, and the pattern would repeat. I said, “Well, we’ve heard a lot from me, but we have the head of Communications and the head of Legal here. I think it would be interesting to hear their thoughts on this.”

Up until that point, neither of those people had said much at all. The head of Communications said that we were edgy, and that if we as Riot started chipping away those edges, we would become shapeless and bland, like EA or Blizzard. I responded that if we told everyone starting today there could be no more rape jokes in presentations and talks, it would still be a multi-year effort for us to no longer be edgy.

I remember trying to appeal to the business aspects of the behavior, and how it opened us up to legal liability. The head of Legal did speak up and asked if we were concerned about legal liability. She was seated to my left, and I was seated on Brandon’s left, where he was at the head of table. Brandon extended his arm past me and held up his hand in front of her and hushed her, saying we were not going to talk about that.

That was pretty uncomfortable.

There was more talk about culture and some people being too sensitive. The head of Legal spoke up again, saying that it wasn’t that hearing guys say the stupid stuff they did all day made her sad or upset, it just made her want to punch them in the throat because she was sick of having to hear it all the time. I really liked that part.

After a bit more talking, I was asked what I thought. At that point I told the group it seemed like this was supposed to be some form of corporate reformative therapy, where they kept repeating stuff then asking me if I agree until I eventually do, but I knew how I felt about it, and it wasn’t going to change.

By then, this 30-minute meeting was approaching one hour. I think everyone was pretty frustrated. We wrapped it up abruptly, and Brandon thanked me for speaking up because he was sure it wasn’t easy, and shook my hand. I asked them how many other people had raised this concern, and they said I was the only one. I told them that was something to be concerned about, because I was not the only one in those original 160 people who had a problem with it.

As we walked out of the room, the head of Legal stopped me and said to tell the women that came to me that they could contact her to talk. I replied, “Based on what just happened in there, there’s no way I would recommend they talk to you.”

Not long after I got back to my desk, I had a new meeting invite for an hour with Marc the next day. I took it as my first sign that the meeting did not go over well.

I was feeling quite rattled, so I pulled aside a confidant who was a Riot veteran since launch and told him about the email I sent and the meeting. Watching his face as I told him, I could tell this was pretty serious. He calmly asked me, “How concerned are you about your career and future here?” I replied, “Well, quite a bit, but not enough to compromise my principles on this issue.” He advised me to recant what I said, and that if I did not, there was likely both a ceiling and probably a wall to my career progression at Riot. I was thankful that he was willing to give me that unvarnished assessment.

In the next-day meeting with Marc, he shared that leadership was not convinced that I was fully bought in, and that they had put a great deal of trust in me with the opportunities I had been given. I told him that if moving my young family across the country, away from everything we knew, and pouring myself into Riot counts as bought in, then yes, I was. But if being bought in meant that I had to have the same sense of humor that they did, then maybe I wasn’t bought in. It was a good talk, and he was very understanding as we talked through the situation.

The Aftermath

Outside of those two meetings, no one else ever talked to me about that incident, including people I was close to who were on that email thread based on my email to Brandon. I had the strong impression that the incident was something we were never to speak of again. However, things clearly changed and began to get a bit weird. I realized my future at Riot was now limited and would need to start looking for something else. I found an email I sent a few weeks after the meetings:

Things continue to be precarious and dissonant in my current role. The big issue I had mentioned has been sort of swept over, with the (unspoken) caveat that I am on "culture fit" watch. There are a number of folks on the floor who could really turn things around, but I'm not sure they'll be listened to and not be overruled by leadership whim.

On a personal level, I feel very alone and "unsafe" at work, having to watch what I say around whom and always be filtering what I say based on how it might be misinterpreted or misused.

A Martin Fowler saying I am fond of is “You can change your organization, or change your organization.” I concluded that I was not going to be able to effectively impact the issues with the culture at Riot, and my first significant attempt at raising concerns had put my job in jeopardy. That was painful to accept, because it meant leaving such great work with so many great people. I chose to leave quietly in February 2014, and not publicly state why I left.

For the many dear people I left behind at Riot, I feel a bit of closure for you to know that I did not leave you all simply because a better opportunity came along. It grieved me to not tell you that I left because of these issues. Know that I missed you all very much, and I have watched your career from a distance, delighted to see so many of you continue to grow and excel.

The Stark Landscape of Today

Cecilia D’Anastasio’s Kotaku article “Inside the Culture of Sexism at Riot Games” appeared in my feed the morning after it published. Reading it, all the old pain and memories came back as if my experience had just happened. I was not involved with the article, but within hours I began receiving messages asking if I was a source. I spent years making myself move on from that loss, and my wife and I resigned ourselves to having paid a steep price for speaking up, with no impact on the situation at Riot, and with only a handful of people sharing that secret with us.

A narrative in my head the last few years has been that the sexist environment at Riot would eventually lead to an issue bad enough that things would be turned around. From what I read in the article, and in the stories of women who have spoken out about what happened to them, I see that I was far too optimistic.

The last two weeks have been an exhausting re-engagement in the narrative surrounding Riot’s trail of sexism-related issues. I am hopeful that the stories that have come to light will lead to permanent, significant change at Riot. I believe it could still become a great place to work. At one point a few years back, I even spoke with Riot about possibly returning, but it was not meant to be. There are many good people there, and I believe they have it in them to overcome this challenge, but it will have to begin with leadership.

I do not think that much of leadership would actively condone sexism and the mistreatment of women. However, when confronted with what they would need to change about their behavior to prevent an environment that nurtures sexism and mistreatment of women, they have an established record of being unwilling to make those changes.

The third core value of the Riot Manifesto is “Focus on Talent & Team.” Women are a big part of that team. In light of all the painful stories that have emerged, it seems Riot still has an environment where women are made to feel unsafe and can be treated in awful ways with little to no consequence for those who mistreat them. A lack of focus on part of the team is a failure to focus on the team. I wish Riot the best in their journey to make it a better place.

And if they don’t, as Martin Fowler says, “Change your organization, or change your organization.”

IBM developerWorks Podcast: Barry Hawkins on agile software development

Earlier this year, my friend Andy Glover interviewed me for season 4 of his IBM developerWorks Java technical series Podcast (RSS, iTunes, MP3 download) on the topic of Agile software development. The episode is titled "Barry Hawkins on agile software development" and runs 41:03 in length.

This was an enjoyable interview; I've known Andy for years, and his style as an interviewer is quite comfortable and flows conversationally. What I really enjoyed about the venue is that it afforded me the chance to talk about software development, the Agile ecosystem, and the primacy of a healthy company culture in ways that I typically do in one-on-one or small group discussions, or talks at conferences that don't get recorded.

Here is a rough outline of the discussion with timing marks should anyone wish to jump straight to a given topic:

  • 00:55 - How I got here: my journey into software and then Agile
  • 05:50 - Things weren't always waterfall; Agile is a rediscovery of things lost
  • 11:12 - It turns out Agile is hard, but not because the old way was better
  • 12:25 - The underlying cultural elements of a healthy Agile environment
  • 20:35 - None of the Agile elements stand well on their own; they work best as complements to one another
  • 26:05 - As a newcomer to Agile, Lean, XP, and all this stuff, where should I start?
  • 29:25 - No matter what: Get better at interacting with the other groups in your organization
  • 31:30 - How to keep cross-functional interaction from becoming death by meetings
  • 36:35 - The scarcity of good ideas, and why they get expressed over and over

I hope you enjoy it as much as I enjoyed recording it. A big thank you to Andy and the IBM developerWorks folks.

Empirical Process Control: Why Scrum Works

Being in my ninth year of applying the processes and technical practices of Agile and Lean software development, people are sometimes surprised to hear me say that Scrum is still my preferred process. Let me explain.

Scrum was designed to enable empirical process control for software development. Of all the things that are important to understand about Scrum in particular and Agile/Lean concepts at large, this is the one fewest people seem to have heard. Why is this important?

Scrum's foundation in empirical process control is important because its model that fits the realities of creating software. Consider the following succinct definition from Wikipedia's short entry on the topic:

The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. - Wikipedia - Empirical process (process control model)

Let that compound sentence sink in for a moment. How effectively does that summarize your experience as a professional involved in the development and delivery of software?

Using empirical process control requires three basic elements: transparency, inspection, and adaptation. Transparency ensures that all the elements a process (I often define that as everything involved in going from concept to customer) is openly observable. Inspection is the activity of taking that observation enabled by transparency and critically evaluating how work flows through the process (in software, our cross-functional team). Adaptation takes the insights gleaned from that inspection as a basis for making incremental ongoing improvements to the process.

Scrum's transparency comes in the form of an openly viewable Product Backlog, highly-visible information emitters in the form of Task Boards and Burndown Charts, a Daily Standup, Sprint Reviews, Retrospectives - all of that exists to clearly convey the flow of work through a cross-functional team. Scrum's inspection comes in the ongoing daily observations and interactions of the team in moving work across the Task Board, and culminates in the Retrospective with the open, healthy discussion of what is working well and what is not working well. Scrum's adaptation begins in the Retrospective, where the team identifies a few things to change in the next Sprint, then continues forward as those changes are implemented.

There is an indirect benefit to this application of empirical process control that, in my estimation, outweighs its immediate value. Through this process, people across functional designations are interacting with one another more than they ever had before. As they interact, they not only do the work, they think and dialog about how they do the work. Built into the cycle of transparency, inspection, and adaptation is this ongoing mental prompt for the group to ask itself, "Now why is it we are doing things this way?" Year after year in many different settings I have seen this result in a healthier group of people who are steadily improving how they work together.

Ken Schwaber emphasized the centrality of empirical process control quite a bit in the book Agile Software Development with Scrum, but it's in the second half of the book. People rarely get all the way through books these days. So, I'm not exactly shocked when I bring up empirical process control when talking about Scrum and Agile and people tell me it's the first they've heard about it.

Do not take these words to imply that Scrum alone is sufficient in creating a healthy Agile/Lean team. Mind you, it's always accompanied by the other things that make for a holistic Agile/Lean environment: User Stories, testing (preferably Test-Driven Development, but not to the point of religious zeal), effective use of version control systems for change isolation and integration via branching, merging, etc., continuous integration, and, most importantly, a culture that is healthy enough to give all these things a fighting chance at taking root.

Barry Hawkins of All Things Computed coaches groups to successfully apply the processes and technical disciplines of Agile/Lean Software Development. In addition to coaching, Barry practices what he preaches when he develops software on contract as work for hire.

The Discipline Deficit

I consult with all sorts of companies looking to adopt elements of process and practice from the Agile/Lean offerings. Whether it's Scrum, Test-Driven Development, User Stories, Test Automation, Continuous Integration, Agile Estimation and Planning, Sprint Planning, or Sprint Retrospective facilitation, one challenge pervades across most scenarios. I have come to call it The Discipline Deficit.

A disheartening number of groups who take up a given Lean or Agile practice or process underestimate the amount of discipline required to master and sustain it. As a result, they either put forth a half-hearted effort and the attempt flops, or they get off to a good start only to abandon it. The unfortunate outcome of either of these scenarios is that the people who interact with said group are left with a rather bitter taste in their mouth, and as a result even the mention of the word Lean/Agile/Scrum/etc. becomes a trigger for painful memories and a general sense that whomever uses these terms is someone to be avoided.

I suppose this should not be a surprise; humans have a fairly poor track record when it comes to resisting promises of gaining something for nothing. There are more than enough opportunists out there selling Agile/Lean as a silver bullet of sorts that turns even the muddiest sow's ear into a gorgeous silk purse while requiring little to no effort beyond mimicking several steps and leaving the existing culture intact, no matter how dysfunctional it may be.

So, once again let me declare that Agile/Lean practices and processes are neither substitute nor remedy for hard work, but rather effective vehicles for structuring and managing hard work. They are also wonderful tools for thinking about the way a group works and its culture, providing information that can be used to improve it - once more through hard work. If you are going to give any of these things a try, consider the cost both in effort and cultural impact. There is no shame in deciding not to apply them; in some cases it actually reflects wisdom and maturity.

Is Agile/Lean as good as it gets?

I was recently catching up on episodes of The Java Posse, and came to the one that features an Open Spaces topic I convened at last year's Java Posse Roundup, Should We Shoot Agile in the Head? It was a vibrant conversation with plenty of input from experienced people. At the 49:50 in the recording, D. J. Hagberg posed an excellent question:

"Is Agile[/Lean] as good as it gets?"

I added Lean, since the question really applies to both, their overlap being so great.

The short answer is no.

What D. J. is asking in the context of that conversation is something I wish more Lean and Agile practitioners were asking themselves. Is the full-fledged adoption of a given process as canonically defined by some authority the goal? If so, to what end? What does that buy us? Is that a guarantee of success?

I will tell you what is "as good as it gets".

Working as part of a group of talented, disciplined, and motivated people to build excellent products in an environment where trust and collaboration cross the boundaries of functional roles with just enough structure to hold things together is as good as it gets.

Agile/Lean processes, tools, and practices can greatly facilitate those things, but they will not create it. At the end of the day, yes, you are in fact going to have to get better at working with others. If you are applying anything Agile or Lean in your teams, ensure that it is with the aim of fostering trust and collaboration, executing tactically with strategic vision in mind. And yes, that is not easy; excellence has never been easy.

Agile: Your Mileage *Will* Vary

There is one question I can guarantee someone will ask as I begin an engagement with a new client. It usually comes in the second half of the first major session I have, called the Agile Orientation. By that point in the initial training, we have covered the roles and components of Scrum, using it as the primary (and my favored) option for an effective Agile process in most businesses. The looks on at least a few faces at that point let me know that people are starting to process just how disparate their current work life is from what I am describing. One of the more outspoken folks usually asks something like this:

If Agile requires all these things, and we can only implement part of it, is it still worth doing?

The answer is yes, with one caveat. A partial adoption results in partial benefits, so expectations should be adjusted accordingly.

I think that's one thing that most groups adopting Agile miss. They acknowledge at the onset that they cannot or are not willing to implement several (often crucial) elements of Scrum, but they sill expect to be "just like the stories" they hear at conferences. But, of course, it doesn't end up being the utopia that either they envisioned or some hand-wavy, hands-off coach sold them.

The real foolishness comes when practitioners blame the process they never even managed to implement for their less-than-satisfactory results. I am seeing this disturbingly often of late. People are speaking ill of Scrum, and when you manage to get a bit of context out of them, it turns out they don't understand it, and their attempts to apply it verge on abominable. If all a group managed to do was have a daily status meeting where some or all folks were standing and have people commit to work in variable-length sprints, can they really be that surprised to not see much benefit?

Yes, Agile is still worth doing, even if you cannot do everything at once. Any improvement is worthwhile, even if the full potential is not realized. Just be sure that expectations are adjusted. Consider the following comparison from another area of life:

If you signed up for a 10k race, and the morning of the race you decided to walk rather than run it, should you really be surprised or disappointed if it takes you 6 times as long as the first 100 runners across the finish line?

There's a direct relationship between how fully you adopt Agile process and practices and the amount of impact or improvement within your group. When adopting Agile, it's not that your mileage may vary, it's that it will vary. Accept that, and you'll spare yourself a fair amount of self-inflicted disappointment.

Is it just my company that has a hard time with Agile?

After an Agile adoption is underway and the feedback mechanisms of most Agile processes begin to function, one or more team members usually ask me something like the following:

Is it just my company that has a hard time with Agile?

No, it's not just your company. However, don't take comfort in that.

I shared something on Twitter that I think sums up why companies have a hard time with Agile:

Agile practices and processes serve motivated, self-directed teams who work hard. It does not create them. @barryhawkins

When most groups decide to start embracing any Agile process or practice, they usually begin by attempting one or more of the discretely observable activities. This is almost always undertaken with no understanding of how that one piece fits into the cohesive whole of the given process or what underlying cultural elements are assumed to be present in order for it to work as expected. This is how you end up with a team having a "daily standup" (even better if it's called a scrum) where most folks sit and talk about their day while staring at the wall, floor, or someone's pen, waiting for the magic to happen. (Spoiler: It doesn't.)

Why would a group even think this would work? Most likely because some overzealous (and typically unseasoned) practitioner or charlatan "coach" sold them on "Agile" (the fact that it was used as a noun is often your first red flag) as yet another silver bullet. You simply begin mimicking these few things that someone heard about in a talk (no need to read up on them; it sounded really simple), and sooner or later the excellence will kick in. The rhetoric usually reads like an infomercial for commoditized excellence in software development.

If you have a hard-working, self-directed team, an Agile process will most likely add some structure to your operation and show you areas to keep improving. If your team exists within an unhealthy culture, that is where it will begin to encounter its greatest difficulties. Effective cross-functional collaboration does not come about as a result of declaring a group "Agile". The team will have to really push their ability to communicate and forge relationships with cross-functional groups. Be ready to adapt as you find out who is willing to work with you in this way and who is not. You can start a decent-sized cultural upheaval before you know it; count the cost of such a thing and decide if it's worth it.

If you have an average team in a company where the technology is an afterthought, that process will probably be somewhat like salt on an open wound. Have you ever heard of a person who sent to rehab or for whom an intervention was staged, but they were nowhere near ready to admit they have a problem, much less deal with said problem? The outcome is seldom desirable, typically driving a wedge between those desiring to help and the one in need of help. Bringing an Agile process into a place that sees the current situation as perfectly acceptable is much like that.

If your team and the company it works for do not have a compatible culture for fully embracing a process like Scrum (that is my preferred one), prepare yourself mentally and emotionally for the fact that it will not "look like it does in the book". That doesn't mean you should not try. Almost any place there would be benefit from increased communication and accountability.

Agile processes and practices are hard for a reason; they are vehicles for pushing forward and honing your craft. Activities that drive toward mastery are always difficult; do not be surprised by this.

Ask an Agile Coach: What is an Agile Coach?

This installment of the Ask an Agile Coach series is a question normally asked by persons outside my field, but lately I have been asking it myself:

What is an Agile Coach?

Good question. I am not sure anymore.

The more I encounter others who call themselves Agile Coaches, the more I think I may not be up-to-date on what that is supposed to mean.

As I have historically interpreted it, an Agile Coach is someone who first actually established a proven track record of successfully leading a series of Agile adoptions as part of the actual teams. The insight, perspective, and expertise gained through that effort are what enable them to coach others. Multiple Agile teams in varied settings challenges what a person "knows to be true" and (hopefully) beats some humility into and the dogma out of them.

I have been under the impression that an Agile Coach also understands software development and the technical practices that support an Agile team. One must understand why testing, automation, code review, and pair programming exist. One must know what it feels like to work both with and without these things, know why professionals should adopt these practices, as well as when one or more of them are not a fit for the culture. It must be very strange to have management bring in a coach who tells you to do these things but cannot show you how.

I also thought that coaches should understand how to apply an Agile process in a way that stresses cross-functional participation. If what a coach is doing isn't helping the company to function more effectively as a whole, I fail to see the point. Agile Software Development is neither a defense mechanism for engineers nor a tool for more effective exploitation by management.

It feels weird to have to point this out, but I believe a coach should understand Agile estimation and planning techniques, especially the ones laid out in Mike Cohn's books. Estimating and planning are among the most painful parts of software development, and one of the most fulfilling parts of coaching for me has been mentoring groups in Agile estimating and planning.

I also think an Agile Coach is someone who can say no. Agile Software Development is a challenge at best, and a cultural nuke at worst. There are places where the introduction of Agile process and practices would wreak havoc. I suppose the toughest part of this is that it requires a willingness to turn down paying work.

I am seeing things these days that make me think my idea of what an Agile Coach is might be incorrect. If it is, I might need to stop using that word. It doesn't mean what I think it means.

Ask an Agile Coach: What Team Members can be shared across multiple Scrum teams?

Welcome to another installment of Ask an Agile Coach. Today's question centers around how to structure teams in light of constrained skill sets in an organization:

What technical roles, other than QA, can be successfully shared across scrum teams? DBA, UX, etc.? - @jakejgordon

Strive to have people in dedicated teams; only share in order to get work from concept to customer.

Any software application of substance requires a collection of specialized skills. A healthy, cross-functional team will have a pool of diverse talent: programming (in at least one language, but often more), testing (QA), database administrators (DBA), business intelligence (BI), user experience (UX), operations/infrastructure (OPS/INFRA), and others. However, some of these skills are not used enough to occupy a single person's work from week to week on a single team, so persons with those skills are allocated across multiple teams.

Recall that, with Scrum (and other Agile processes as well, though Scrum is most explicit about it), the process is designed to provide empirical process control in software development. The reliability of velocity as a measure of throughput depends upon the stability of the team. Therefore, an organization should try to structure its teams to consist of people dedicated to the workloads they serve. When team members are allocated across multiple teams, their available hours for each team can vary from sprint to sprint. Since these people are usually specialists like BI or UX, this variation is happening with the most constrained set of hours available for Sprint Planning. Any user story in a sprint that requires these hours is at risk of carryover if the team planned against hours that turned out to be unavailable.

The undesirable result of this variation is an unstable velocity and increased carryover of user stories in sprints. This in turn erodes the reliability of planning and estimation activities. The team shows itself to be unreliable and unable to deliver on commitments, eroding confidence and trust with stakeholders and management.

The primary risk with sharing team members is that Scrum Masters and management often do a poor job of accounting for how those peoples' time is allocated and managed, which inflames the symptoms described above. Bear the following points in mind when sharing team members:

Include all your cross-functional team members in user story writing, estimation, and Sprint Planning sessions. User stories that account for all the effort needed to go from concept to customer are more reliable and not as prone to surprises during delivery in a sprint. Prefer the bad news of resource constraints over the surprise of planning against naive user stories.

Avoid sharing a team member across more than two teams. Once a person has to divide his or her effort across three or more teams, estimates and available hours become unreliable. Furthermore, the more teams a person has to participate in, the more their time is wasted in switching their mind between contexts. They also end up in recurring events like Sprint Planning, Sprint Reviews, Backlog Grooming, and Retrospectives for each team, leaving a meager number of hours to do actual work. If a person has to be shared across more than two teams, that is a sign that another person with those skills needs to be hired.

Use the valuable information from Sprint Planning and tracking to inform the budgeting and hiring process. Is QA/BI/UX constantly a shortage in Sprint Planning? That is the gentle, loving tap of the clue bat on the collective skull of management to stop hiring more software developers and allocate the salary budget in a manner more appropriate to the actual work being done by the group. Hidden costs of effort are being uncovered as a result of properly applying the transparent, reliable process that is Scrum, and that is a good thing.

Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Ask an Agile Coach: Should I count partially complete user stories in my velocity?

Hello readers, apologies for the lack of posts lately; lots of work at hand. Today's Ask an Agile Coach question comes from a comment on the last installment, which is rephrased here. In one form or another, I have gotten this question for years now:

Should I count partially complete user stories in my velocity? For example, if I have a 100-point story that's almost done, should I add 80 points to my delivered points total for this sprint?

The answer is no, you should not.

Remember that Scrum was designed to enable empirical process control for software development. The team is committing to work in fixed intervals, with the intent being that a team becomes quite proficient at knowing how much work they can move from concept to customer within that fixed interval. To that end, the points that go into velocity are points delivered. Delivered points come from stories that are completed. When stories are incomplete, they are carried over, and velocity is lower than expected for the Sprint. Hopefully, these points plus the additional work pulled in will cause the next Sprint to have a higher number of delivered points and the two values will level one another out.

If a team or Scrum Master insists on counting part of a story's points in velocity, they are masking a symptom and thus choosing to ignore the underlying causes. This short-circuits the process and the valuable feedback it provides.

If a team finds itself with carryover continually affecting velocity in a negative manner, it is usually an indication that the team needs to improve their ability to plan and commit to work within a Sprint.

One area to target is honing the ability to break work down into thinner vertical slices of user-oriented functionality. If stories are perpetually 50-80% done at the end of a Sprint, revisit the team's approach to user story writing and trying to carve smaller functional slices (but not so small that you violate the INVEST heuristic from Bill Wake; an alarming number of practitioners have fallen into hyper-granularity in their stories).

Another area to address is the cross-functional team's (and your Scrum team is cross-functional, right?) understanding of what it takes to go from concept to customer. If stories seem to invariably look smaller or the team seems to perpetually overcommit, it may be that some of the more vocal team members are expressing estimates that reflect a myopic focus on simply the writing of code instead of all the tasks involved in completing a given story. Encourage the other cross-functional members to speak up in User Story writing, Sprint Planning, and Backlog Grooming about what they need to do to complete the stories in question. This has always resulted in more accurate story sizes for me over the years.

Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.