Category Archives: Leadership

Don’t Be A Jerk

Posted on by
7

I’ve been threatening for years to put together a presentation titled “Everything I needed to know about Leadership I learned while running a guild in World of Warcraft.” I still might someday, but I’m annoyed with myself for continually talking about it and not doing it, and one of the points I want to make is top of mind today so I’m just going to write it down in a post and consider it pre-work for my epic future Agile Alliance presentation.

I started playing World of Warcraft shortly after it was released in 2004. I had a small group of friends who had been playing City of Heroes together and we all decided to try it at the same time. When enough of us had gotten the game and decided to stick around to do so, we started a small guild (a guild, for those of you are unfamiliar, is a means to communicate and share resources in the game with a specific group of people). Eventually we met another guild that was populated by people who we thought were neat, and we decided to merge the two guilds together.

For some reason I agreed to lead this new guild.

I won’t go into a lot of detail as to why a guild needs leadership, because it’s not really relevant to this post, but the very short version is that there is a lot of content in the game that requires large groups to complete, and part of running a guild is to help schedule teams to take on that content and establish agreements around how any rewards won from beating it would be distributed among the group. Guild leaders also establish the culture of the guild (ours was considered a “casual” guild, with mostly older players who had responsibilities that prevented them from devoting excessive amount of time to the game) and will also set up rules around acceptable behavior by guild members.

When we formed our guild, we had one rule: Don’t be a Jerk.*

For a while, that worked just fine. Everyone understood what being a jerk meant, and we were all pretty good about not being one.

But then the guild grew. We kept adding people who we didn’t know as well as the original members. As our numbers expanded, the line on what everyone accepted as “jerkish” behavior began to get fuzzy. Common sense, it turns out, is not so common. Especially when you’re dealing with a diverse group of individuals who are paying for the privilege of playing a game. People with different backgrounds, who come from different regions of the world, and have a variety of socioeconomic situations, genders, ages, and sexual orientations (not to mention skill levels). Heck, one of our prominent members was a retired grandmother who used to send me cookies every Christmas.

Mardi, if you’re still out there my address hasn’t changed.

Eventually something happened that I, and the folks who helped me run the guild, couldn’t ignore. I don’t remember what it was, specifically. All I remember is that our response to the thing that happened was to create a new rule, so now we had two of them. It wasn’t too long before another incident got our attention, so we created a third rule. Then a fourth. A fifth. You get the point.

When I finally stopped playing the game in early 2009, I believe our rule book was three pages long.

We would make broad announcements about how we have “noticed certain behaviors” and how those behaviors “violate the spirit of our core value of not being a Jerk.” If the person in question continued doing the “thing” we had created the rule for, we could point at the (newly expanded) rules list and accuse them of violating it, thereby justifying our decision to remove the person from the guild.

You know what we never did in any of these situations (before it was too late)?

Talk to the person in question.

Instead of having an open, honest discussion about whatever the infraction was that caused us concern we avoided confrontation entirely and hid behind bureaucracy.

Our reward? More headaches. The bureaucracy that was protecting us from being the “bad guys” continued to grow and become more complex, and eventually got to the point where we spent more time managing rules and people than, you know, playing the damn game.

Eventually it got to be too much for me and I quit playing. All the enjoyment had been sucked out of the game for me, and I walked away. I still have friends who I met playing WoW, and some of them are still playing and in the guild I helped create, but I canceled my account almost 14 years ago and haven’t looked back.

So what does any of this have to do with Leadership in the professional world?

The first, and most important, lesson I took from this was that creating rules to deal with people problems is a no-win scenario. I’m not saying you shouldn’t have rules, codes of conduct, etc…but if you’ve got someone on your team who isn’t working well with others in some capacity, creating some kind of rule, procedure, or process to deal with that person is not being a Leader. It’s managing (and managing poorly, at that).

The other big lesson I learned is that by creating a rule that applies to all members of a team when only one person is responsible for doing the “thing” that caused the rule to be made, you create a situation where the unintended consequence of your action is to cause people who have nothing at all to do with the situation to suddenly worry that THEY were the reason the rule was created. For example, say you have a person in your organization who has some kind of issue with body odor that is disturbing others and instead of having a conversation with that person you send out an all-users e-mail reminding the entire company that “we all have to work together in small spaces” and to “please be mindful of how our personal hygiene might impact those around us.” The person who inspired the e-mail might not think it is about them, or they might realize it is and get horribly embarrassed and/or resentful. Even worse, people who had nothing to do with the original announcement may start wondering if they are the reason the email was sent in the first place.

This lesson shows up in the Agile Manifesto, of course. “Customer Collaboration over contract negotiation” is one of the four values found in the manifesto. Talking with people and working out situations directly is much more effective than hiding behind contracts (and what is a list of rules in an organization but a contract that one agrees to abide by to continue working there?), and how can we argue with the fact that most effective means of communicating information being face-to-face communication?

If I knew then what I know now, I’d have spent a lot more time talking to people and a lot less time managing a list of complex rules. The short term discomfort of having a difficult conversation pales in comparison to the drudgery and annoyance of dealing with the red tape of a ridiculously long rule book.

*In the interest of full disclosure, the word wasn’t jerk. I think you get the drift, though.

Where I want to be and who I want to be

Posted on by
Reply

This post was “written” almost a year ago. I was experimenting with using dictation tools to write a post on my morning walk, and the end result was pretty scattered and required a lot of editing. I got about half way done, had to move on to other things, and promptly forgot about it. This morning I stumbled across that draft in progress and decided to finish it up. Honestly, it was rough. I had to remember what was on my mind a year ago, and I went off on some completely unrelated side rant that was about a thousand words long and needed to be edited out. I think the end result here is worth posting, though, so here it is.

The company I work for recently went through a major reorganization. A new department was created for our business unit and our team was moved into a new vertical under a different executive. A VP position was created to head up the new department, and another senior leader was given that position to help align all of our Agile/Lean/Project/Strategic activities.

It’s a lot of change. I was, admittedly, quite shaken when it happened. I’ve had my cheese moved more than once at my current job, but this one felt overwhelming at first. I don’t feel that way any more, and in fact I’m really excited about all the changes, but that initial jolt was pretty big.

One of the reasons it was such a shock to my system is because I was moved into what we are calling the “process” vertical in our organization. As someone who believes in and supports Agile, being in a group that seems to be on the “processes and tools” side of the “Individuals and Interactions” equation wasn’t a look I was happy with. I’m still not entirely keen on the optics around it, if I’m being honest, but I do believe that in our current structure we landed in the right place.

In any case, I was meeting with my new boss on Monday (the above mentioned Vice President of our newly formed department), and we were having one of many “getting to know you” style conversations we’ve had since the change. While we’ve worked together for many years at this point and have a perfectly amiable working relationship, we don’t really know each other all that well so we’re spending some time working on that. In our conversation on Monday, he asked me where I wanted to be in five to ten years.

Now I need to go ahead and state for the record that he knows about my cancer and said right up front that he realized his prepared topic for the day probably wasn’t something that was top of mind for me at the moment. I concurred and stated that “alive” was really my top-of-mind goal, but since I intended to achieve that one it was totally cool to talk about what else I’d like to be doing and we did so. In the time that has passed I’ve thought about it some more, and that was the path I took to starting this post.

When I reflect on my early days in software development, I see a perfect example of how my mind works. My first job was with a company that sold ColdFusion based auction software. The original person who wrote the code did so in a way that was most efficient at the time he wrote it. The internet was slow, and any extra white space in the background of a page could cause longer load times, so he removed any characters that were “extraneous” from his code.

The result, while readable to a visitor of the site, was a solid mass of text that was nearly impossible to decipher on the back end.

As my responsibilities there grew I eventually got access to that code base and was charged with helping to fix/improve the software. Every time I had to access a page, I would poke around in it and make it better. I would add comments where none existed. I would explicitly name variables from x or y. I would tab-delimit nested code. I would update deprecated functions or replace code blocks that were inefficient. What I was doing was removing technical debt, but I had no concept of what that was at the time. I just wanted to understand how the code worked, and I wanted to help make it better.

Which is a perfect example of how I look at the world. I want to understand how it works, and I want to make it better. So when I think about where I want to be in five or ten years, my answer is really just as simple as that – I want to have made the world a little bit better. To do so I need to keep learning. To do so I need to look for ways I can improve the code of the world around me, whether that is in my personal life or professional one. I want to take my experience, my influence, and my knowledge and apply it in little ways to make incremental improvements for as many people as I can.

But, ultimately? I still want to be here.

Is it SAFe?

Posted on by
Reply

When I look at the diagram above, I get an absolute headache. Yes, I’m one of those agilists who sees the Scaled Agile Framework diagram and wants to absolutely claw his eyes out. Nothing in the above screams “Individuals and Interactions over processes and tools” to me, and when I think about the level of bureaucracy needed to support something as bulky as what is seen in this picture I want to run screaming.

So, it might come as a bit of shock to know that I arranged at Leading SAFe 4.0 certification class at our organization last week. I recognize the fact that the structures around SAFe are very comforting to people who are trying to transition from a command and control mindset, and I have been challenged by my mentors to learn more about things that are counter to what I believe. You know, that whole “seek first to understand, then be understood” practice that is part of the 7 Habits of Highly Effective People mindset. I’ve previously taken Scrum@Scale training, and (like Scrum) itself it really resounded with me, but several of the members of our transformation team really like the SAFe model. With all of that in mind, I set about to get a better understanding of how SAFe works, and as a result I am, as of yesterday, a certified SAFe Agilist.

That, coupled with all my other certifications and $5.00, gets me the proverbial cup of coffee at Starbucks, and not even a venti one.

While I’m still skeptical about how something this complex would work in our relatively small organization (our back-office staff is somewhere around 150-200 people), I must admit that the framework isn’t all that bad. It’s clear that the creators really did design it with the Agile Manifesto in mind, and throughout the course of our two-day training I saw many things that directly referenced back to it. One of which has been top of mind for me lately.

See, in our organization we’re currently at a state where we have been “doing” Agile for several years now. We’ve got teams outside of IT using it. We have area leaders and executives involved in the process. We’ve got a corporate Agile vision statement, and we’re working closely to align the objectives of the organization with Agile practices. It’s all great stuff, and I’m very proud of the progress we’ve made, but as we bring more and more people into the fold, the question of “how do we know we are successful” keeps cropping up. As the Enterprise Agile Coach, this is a particularly vexing question for me. People look to me to explain to them how we know Agile is “right” for us, and they want objective evidence to back up when I say that it is. This frequently results in questions about what metrics we can use to show success, and I loathe metrics. Well, let me quantify that statement. I think metrics are fine as learning tools. I think metrics can give teams data to use to improve. I’m not so anti-metric that I think the practice of collecting data is worthless, but I do believe that metrics can very, very easily be distorted and become useless. I can’t tell you the number of meetings that I have sat in where a person who was presenting a metric did so by opening with “now keep in mind that…” and proceeding to explain why, exactly, the metric they were sharing was completely inaccurate and shouldn’t really be a factor in judging success (“but it will be better next quarter”). When you’re talking about team metrics? Forget it. Measure a team by number of lines of code completed? They add unnecessary code. Tell a team they should increase their velocity? Suddenly all the user stories that would have been 3’s become 5’s.

This is why, in the manifesto, there is a principle that specifically addresses what “success” looks like in an Agile environment –

Working software is the primary measure of progress.

There it is. Simple. Clean. Straightforward. If your team is consistently putting out quality work, the things you are doing are working.

What does all this have to do with SAFe? One of the things I learned in our class, and one of the things that made me think that maybe SAFe wasn’t quite the monstrosity that I thought it was, is the fact that in the SAFe world the ultimate measure of success is the System Demo.

The one real measure of value, velocity, and progress is the demo of the fully integrated work from all the teams during the prior iteration.

Not velocity.

Not burndowns.

Not ROI, or ROA, or lines of code created, or number of tests passed.

Fully integrated work.

Teams getting things done.

I still take issue with the fact that, in both the SAFe model and Scrum@Scale, there is an insistence that all the teams be doing the work in the same manner (although SAFe did recently concede that some teams could potentially use Kanban instead of Scrum). Frankly, I take issue with a lot of the things that SAFe says you “have” to do to be successful (prescriptive Agile makes me break out in hives), but it gives me hope that they at least acknowledge the fact that no metric in the world shows success better than teams producing quality work.

Agile isn’t a checklist, and your organization will never “be” Agile if all you are focusing on is whether or not you can complete a menu of items and say “yep, we did these things.” Some teams are going to thrive using Scrum. Some will do better with Kanban. Some might just adopt XP practices, or come up with their own way of doing things that works for them. That’s ok. That’s great! The Agile Manifesto doesn’t say anything about following a set of practices. What it says is that, in the end, if the team is delivering value on a regular basis you should get out of their way and let them keep doing it.

Don’t even get me started on how to define “value,” though…

The Past Is The Past

Posted on by
Reply

“Those who cannot remember the past are condemned to repeat it.”

– George Santayana

The first time I heard this quote was in the early 1990’s. Jello Biafra chanted it three times, like a self-affirming mantra of sorts, during a spoken word show at the Ritz Theater in Ybor City. That show was truly life changing for me in many ways. It happened during the first Gulf War, and as a result of what was said there I resolved to myself that I would never be compelled to take another human life unless it was in self-defense (I claimed for years that I had “registered” as a conscientious objector, but that was untrue. I knew what was required to do so, but never actually went through the steps to make it official). I tore up my draft card during that show, and left the scattered pieces on the floor of the venue. I became more interested in politics, and in particular the people who pointing out just how ridiculous some of the things that went on in the world were. After this performance I expanded my reading to include more than just fantasy and science fiction books, and eventually found myself immersed in the words of people like Hunter S. Thompson, Kurt Vonnegut, Ken Kesey, Jack Kerouac, and Henry Rollins.

It was a hell of a night.

Now it’s about 25 years later. Jerry Brown, the vile enemy of the Dead Kennedy’s song California Uber Alles is now a darling of the Democratic Party.  Jello Biafra is still around and trying to change the world, but these days he looks more like someone’s Dad than a dominant figure in the punk music scene. We long for the days when we thought George W. Bush was the Worst. President. Ever. We carry the wealth of human knowledge around in our pockets and we use it to look at pictures of cats. Then there is me. I’ve worked for 15 years with the same company, working my way up through a non-profit corporate chain to a significant advisory position to the leadership group. I have tattoos, and I still have some “crazy” notions like “killing other people is generally a really bad idea”, but I’m definitely not the same person I was when I was so enamored by the words of Mr. Biafra back in the 90’s, and some of the things that stuck with me that night don’t hold up quite so well in my current way of thinking.

Particularly the admonitions about remembering the past.

Now, I’m not suggesting we shouldn’t look to the past in order to recognize patterns that recur in human history. Heck, our current administration is pretty much a text book example of why we should always keep an eye out for another totalitarian government. I’m also not suggesting that experiences in our own personal lives shouldn’t shape our decisions today. They shouldn’t dictate them by any means, but one of the whole points in life is learning from our mistakes.

No, I’m talking – probably unsurprisingly – about living in the past when it comes to your current business decisions.

During a recent meeting amongst some of our mid-level managers, the issue of the lack of project documentation came up. “Back before we made this switch to Agile,” the commentator opined, “we knew exactly what we were getting out of a project because it was in the requirements document. We could go back to that document to make sure we got everything we asked for. And all of those documents were stored on the PMO site, so we could go back and look for them years later so that we could refresh ourselves on why we made the decisions we did in the past.”

I did my best not to run screaming from the room like I’m always tempted to do when someone bemoans the “good old days” of Waterfall development. I took a deep breath and talked to the individual about the values present in the Agile Manifesto, particularly the notion of “Customer Collaboration over contract negotiation.” I talked about the fact that those requirements docs were a double-edged sword, and that they could easily be used against the stakeholder (the nefarious “scope creep” accusations). I emphasized how the stakeholder should be in constant contact with their product owner while a delivery team was working on their product, and how they should be working with the team daily. I extolled the benefits of the Sprint Review and how that feedback loop could prevent the delivery team from wasting time by going too far down a path that is dictated by a rigid requirements document. I said all the things a good Agile Coach should say.

What I didn’t do was express my utter and complete horror at the notion of keeping an archive of documents about past projects.

This is one of the areas where I’m really big on the values from the manifesto. “Working Software over comprehensive documentation.” I get that the manifesto isn’t saying that you shouldn’t document, but for me personally documentation is a monumental waste of time – especially if you’re talking about an environment where everyone is working for the same company. Spending effort creating documents that MIGHT be used by a small group of people is really something I personally take issue with, especially in the world of software development where I’m a proponent and practitioner of self-documenting code.

But more importantly, this is an area in which I feel like it’s important to leave the decisions of the past behind you. My mentor frequently states that “an idea that is good enough will come back in time.” He mentions this in regards to regularly cleaning out the backlog by removing items that have sat around for a while with no action. I look at old documents with a similar eye. Do we really need to spend time going over documents that are years old? Do we need to re-hash old arguments? Do we need to try and remember what the market conditions were at the time that led us to our decisions? Do the rules and regulations that led us to past decisions even exist any more? Have they changed? How much time do we waste digging through archives, planning meetings, and generally getting nothing done when we could turn our ideas over to teams who can produce working solutions?

If your organization is trying to promote a culture where teams can “fail fast,” but you’re still overly concerned with trying to prevent the mistakes of the past, you’re destined to, well, fail. Give your teams the safety to run with ideas, try some small experiments, and learn on their own without burdening them with decisions that are, most likely, irrelevant today. Let them learn on their own. More importantly, open yourself to the possibility that they are going to come up with solutions that are completely different than the ones your organization thought of in the past. Considering how quickly the market is changing these days, that’s much more likely than you might think.

 

Take Me To Your Leader

Posted on by
Reply

Image courtesy of Travis S. via flickr

Image courtesy of Travis S. via flickr

I have never wanted to be a leader. Unfortunately, despite my best efforts to the contrary, I find myself in that position quite often. I distinctly recall the first time anyone ever accused me of actually holding sway over a group of people. I was very young at the time, probably around 12, and in they very stereotypical fashion of that particular age bracket my group of friends had decided that it was time to ostracize one of our own. I honestly could not tell you what it was that he did at the time. Frankly, I am not sure he actually did anything. I think it was just one of those situations where we were experimenting with social structure and power and he was the guinea pig of the moment.

At some point our friend must have told his parents about what was going on and how badly it was hurting him, because a few days into this whole experience I found myself sitting at my kitchen table with his Mother.

Continue reading →