Going To The Dark Side

I discovered the other day that I have apparently gone over to the dark side of Agile. It’s unfortunate, but understandable given the circumstances. You see I’m a manager now. The minute that happened there were some telltale signs that I really should have noticed earlier. I caught myself telling people that I mentor things like, “I am your father…” I’ve noticed that line gets me a few puzzled expressions in the office. It seems to work better with the kids. Then one day the color of my light saber changed from green to red. I’ve seen the movies and everybody knows what that means. Still, I didn’t suspect a thing at the time. Even when I took to wearing a floor length black cloak around the office like some sort of pudgy corporate goth, I just told people I was wearing it because I was chilly. I didn’t fully comprehend the full power of the dark side until I started to deflect impediments.

Deflecting impediments is like a drug. There is this feeling of satisfaction you get when you manage to deflect dealing with an impediment holding up a team’s progress that is like nothing else I’ve ever felt. Well, actually it’s a lot like strangling a puppy. Yup, we’re definitely on the dark side now people. However, deflecting impediments is not as easy as you might think. Just like being really lazy, it is more work than it first appears. In the interests of furthering the evil methods of the Agile dark side, I will share some of my diabolical impediment deflecting techniques with you.

Minimize the problem. The key here is to dramatically downplay the significance of the problem. The team has come to you for help. It’s your job to convince them that it’s not really a problem. It’s really not that bad. That issue won’t slow you down that much. You can work around it. It has always been that way. If you can master this technique you will become the Jar Jar Binks of management effectiveness.

Delegate to the Team. If you can’t get them to acknowledge that it really isn’t that big a deal, don’t worry. The fallback position is to look at them with an appraising eye and say, “Don’t just bring me problems, I respect people who bring me solutions. So what do you propose?” Let them stumble about and come up with some lame idea. Then smile and say, “Perfect, you know how to solve this yourself!” They have thrown the problem toward you and it has whipped about full circle and ended up right back in their laps! I call this the boomerang impediment. This is worth doing just to see the expression of indignant outrage on their faces. Feel free to combine it with some sort of dramatic gesture (a closed fist works well for me). The coup de grace? Tell them you’re going to hold them accountable. Trust me, at this point the evil laugh just comes naturally.

Reject the problem. Take a tip from Obi-Wan. Just wave your hands and say,

“These are not the impediments you are looking for…”

There are couple of strategies that you can use here. You can plead that it’s outside your control. Sorry, not my department. It’s those bastards in accounting. The point is, there’s nothing you can do. You’d love to help, but you can’t. Every time you manage to do this, somewhere in the world a Scrum Master loses its wings. Or if you are feeling really evil, just tell them to take it to the scrum of scrums – nothing ever gets done there.

Together, using the dark side, we can halt the forward progress of any team. Does my voice sound deeper? Repeat after me: “Come over to the dark side and together we can bring the corporate world to its knees!” Now, does anybody know where I can get a black helmet? How about some platform shoes?

XP2011 – Taking Silo Busting to Madrid

Lourdes Vidueira and I have taken the “Silo Busting” presentation that I’ve been doing for about the last two years and we have rather dramatically expanded it into a full 4 hour tutorial session for XP2011. A tremendous amount of research has gone into building this material and I have to say that I’m very excited with what we have put together. Managing conflicts between organizational silos is the very definition of a wicked problem that is rife with complexity (and usually comes with a healthy dollop of chaos on top). These sorts of problems require a multi-disciplinary approach in order to effectively deal with them. Some of those disciplines include:

• Sociology (in-group & out-group formation)
• Psychology (hierarchies, biases & discrimination, personality, group formation)
• Conflict management (conflict models, personality)
• Leadership (personality, hierarchy, vision)
• Organizational Development (vision, organizational structure)

And I’m sure there are even more. Many of these domains overlap and reinforce the other. Like I’ve mentioned, I’m pretty tickled with what we have come up with and I’m looking forward to sharing it with a group of really motivated people. Of course the setting for the conference, Madrid, is going to be fabulous. It looks like there are a lot of great sessions in the program and I will be sure to keep folks posted on the stuff that I attend.

If you are going to be attending, make sure to check out the Silo Busting tutorial on Friday – We’re hoping to make it one of the highlights of the conference!

Finding Your Voice

When some people transition from traditional project management to Agile, they seem to lose their voices. These are people who had great, strong, passionate voices. People who felt they were engaged and empowered to lead their teams to success. And then some consultant comes along and tells them that they got it all wrong. The wise consultant tells them that they are part of the problem and need to change their evil command-and-control ways. They need to be a servant leader – one of the most poorly defined roles ever conceived. Guess what happens to these poor bastards?

They get confused! They don’t know what their job is supposed to be. Everything they used to do is suspect, part of that horrible “waterfall” thing. And now they have a team of people who have been told just how evil they are. Nobody trusts you. Why don’t you just remove impediments and stay out of the way? Don’t call us, we’ll call you. If we need you. You don’t code, so you’re not really that relevant anyway.

Soon people are asking questions: where is the leadership? Why won’t these weak Scrum Master creatures take responsibility for the project? It’s the team’s job? That’s funny, I don’t see the team stepping up…and so it goes. Now everyone is confused. What has happened to that rich voice that guided the team? Now it’s a timid peep. It’s a pale, skinny shadow of what it once was.

And so the journey begins. We sit back, watch the chaos ensue and ask ourselves, is this really my job anymore? I’d do it differently, but apparently I have to say it differently too. What should I say? Meanwhile Rome doesn’t exactly burn to the ground. Not exactly. In fact, people make approving noises. Things are better now…aren’t they? After all, we spent 100 grand to get here. Look at our metrics!

At some point, things start to go wrong for the team. Nobody steps in. The pressure builds. The Scrum Master looks around and thinks to himself, isn’t somebody going to do something? The pressure builds some more. Still no action is taken. And then the levy breaks and there is the voice! The voice that demands resolution. The voice that won’t accept mediocrity. A voice that communicates a clear and compelling vision.

Why do we do this to ourselves? Maybe it’s a journey that we all need to make. Perhaps there are no shortcuts. Maybe it was just me hearing voices again.

Who Is Your Coach?

If you are anything like me, finding a good coach or mentor is a challenge. Frankly, until recently I had a good excuse: I had no idea what a good coach looked like. After doing a little reading I’ve come to realize that there are a few things that I need to find in a coach:

• They need to have model of the discipline or domain that is more detailed and robust than mine
• They need to be able to make a connection with me on a personal level
• They need to be able to provide a coherent vision of what the path to success looks like

You see, it’s all too often that I’ve been in seminars on Agile coaching and realized one of two things: either I really have no idea how to advance beyond my current skill level, or whatever the current state of affairs is – it provides me no guidance on where to go next. At these times I feel stuck in a rut. What I need is somebody who can paint a picture for me of what the discipline of coaching should look like. In the case of someone who is already fairly experienced, that picture needs to be very detailed.

Of course they need to be someone that I can relate to well. This is a tough piece of chemistry to get right. For some people this may mean that they relate best to someone who has a very spiritual bent. For me, it probably means somebody with all the scintillating personality of a marine drill sergeant (on LSD). It’s going to be different for everyone. Maybe it’s because I’m an introvert by nature, but I find it hard to make that kind of a connection. Fortunately, there are lots of other proxies for a coach that are available to me:

• Teams: Being part of a well functioning team provides insanely good feedback and guidance.
• Colleagues: Whether it’s in consultation over a beer or between sessions at a conference, I learn a lot from my peers.
• Social media: There’s nothing quite like saying something stupid in front of a large audience to generate feedback!
• Reflection: I write in a journal, reflecting on what happened in the day, how I felt about it, and what I plan to do about it.

I’m sure there are lots of other obvious or not-so-obvious ways that people obtain coaching for themselves. What are some examples that work for you?

How Others See Us Is Important Too

I was having a conversation once with an executive sponsor who was frustrated by friction between competing organizational silos. One silo adopted Agile, the other stuck with more traditional plan driven development. Each side mocked the other’s “head in the clouds” or “lost in the past” approach to projects.

When I was asked what I thought about the situation I found myself saying something along these lines,

“We (the Agile teams) have become very good at being open and collaborative with each other. We have created these marvelous cross-functional teams and have done a great job of breaking down the walls that used to exist between team members. From an insiders perspective on any given team we have made dramatic improvements to the way we work.”

“However, from the outside we don’t look that much different. In fact from the outside, we still react with hostility when provoked and we don’t offer much transparency into our work beyond using a handful of project tracking tools. It’s just not enough. I have high expectations of an Agile development team. I believe that an outsider who works with an Agile development team should come away from the experience feeling like they were welcomed, informed, and energized. I want a team using plan-driven methods to welcome an Agile team, because they will be that much more likely to succeed. The experience will be one of openness and a general willingness to work together.”

“But that’s not often what we get. Instead we get fear, hostility and resentment on both sides. Some of that is human nature. Some of that is silos. And some of that is because we focus too much on the process. I think we should leave the process out of it. Working on a project is a chance to make friends and meet new people.”

“What I need are people who are friendly, open and honest. People who smile when I walk into the room. People I can crack jokes with. If I lead with friendship, I can make more ground than if I lecture them on Agile practices. People should feel at ease when they work with my teams. They should know that they are safe.”

At this point in the conversation I was:

1. out of my chair
2. pacing the room
3. and gesticulating wildly

The first two meant I was feeling emotional, the last one meant I was talking. I was surprised at the heat of my own passion on the topic. In writing it down, it even sounds naive. But here’s the thing: I’ve worked with enough Agile teams to know that they can be real jerks to outsiders…and that is a shame. I would have hoped that all of that vaunted openness and transparency would make that go away, but it doesn’t.

If Agile in whatever form is ultimately to be successful, then both people inside and outside the team need to feel safe and respected. If you are starting a new team, please realize that getting things working smoothly within the team is critical, but don’t forget to look at how your team interacts with others to – in many ways it’s just as important to the success of your team – perhaps even more so.

Practice #2: Break It Down

How do you go about memorizing a poem? When I do it, I usually break it down into individual lines or phrases and memorize each one piece by piece. Then I put it all together as I build up a collection of individual lines that I’ve memorized. I suspect it works that way for a lot of things we learn. First we break it down into manageable chunks and then we master the smaller units one at time.

One of the things that coaches do in sports is analyze a skill that a player demonstrates. As they do so, they break it down into smaller components. It could be a batters swing that is broken down into the component arm movements, shoulder movements, head movements, hip rotation and foot placement. Overall, the player coordinates all of these pieces into a single unit that we see as the resulting swing, but to the experienced coach, they see much more. The coach may notice that part of the motion isn’t being executed properly. Then they call the players attention to the issue and perhaps they ask them to practice just that part of the motion in isolation. When they have mastered the motion in isolation, they bring it all back together again – hopefully with the end result of a home run hit on game day.

The same thing applies in weightlifting. You may find that you are stalled out in trying to make progress on one of your lifts. A coach will look at the way you perform the lift, and break it down into its component parts. Usually there are sticking points or weak areas in most people’s lifts. Typically a coach helps you identify these problem areas and recommends some exercises that isolate and address that weak area. So you practice just the top part of the lift, or perhaps just the lift off the chest – and you do it over and over again until you have mastered just that small portion of the overall exercise. Then you put it all together again to perform what is hopefully a successful lift.

Obviously it’s not hard to find examples of how we break things down into smaller pieces in order to refine or improve them. So how can we do this as a practice for our projects? First we have to understand what all the components are of the exercise we are planning to perform. Let’s take a scrum planning meeting for example. In a typical sprint planing meeting you might break it down into the following parts:

1. Pre-planning: This includes backlog preparation (Are the stories understandable? are they sized? Have they been prioritized?) Is the product owner ready to discuss and elaborate on the features? Has the planning meeting been scheduled? Is the agenda well defined?
2. Kicking off the meeting: Are the right people there? Is the agenda understood and mutually agreed upon? Are all the materials (sticky notes, whiteboards, etc.) necessary for facilitating the meeting present?
3. Reviewing the stories: Is the team asking questions? Is the product owner prepared to answer them? Are open issues and risks being captured from these conversations? Are new stories being created/deleted?
4. Designing: Is the team prepared with resources to support detailed planning? Are designs/code/tests being proposed? Are requests for additional information being satisfied? Are tasks being captured? Are the tasks getting sized?
5. Commitment: Is the team able to negotiate stories with the product owner? Are there caveats or exceptions that need to be noted? Areas for further exploration?
6. Wrap up: are the notes from the meeting posted someplace for reference later in the sprint? Are there any remaining issues or reservations that need to be addressed?

In broad terms, these are all the things that make up a planning meeting. Doing any one of these things poorly may have an adverse impact on the performance of the team later in the sprint. So there is some pressure to get this meeting right. Inevitably, if you are anything like me, you look at this list and wince a bit – you’re probably seeing things that you could improve. Bingo! That’s what we want to practice! Each of these things can be practiced in isolation.

So, unless we can convince ourselves that we run the perfect planning meeting, the perfect stand-up, the perfect retrospective, then we need to be practicing. All of these activities can be broken down into smaller parts – and it’s very likely that we all do some parts better than others. So let’s start practicing!

Scrumalienation

I’ve been a certified scrum master for about 5 years now. I’ve learned a lot from the scrum community. There have been things that I liked and more than a few things that I had quiet reservations about or outright disagreements with. In my scrum master certification course, Ken Schwaber made it clear that we were joining a community and if we deviated too far from the accepted standards held by that group, we could be rejected by that community. If we were judged to have violated the principles of scrum, or tried to take advantage of the process, he or the community at large, would take some sort of action, legal or otherwise, to protect itself and cast out the offender. He even went so far as to give us an example of specific case where he and others had done exactly that.

At the time I put this in the context of other communities that I was a member of like the PMI. These communities generally define some set of values and then ask you to agree that if you violate those values or are found wanting in some way, you will be excommunicated from the community. The way that I see it, this is integral to the very process of creating a community. At some level it’s all part of defining the membership of the community – its all part of defining the difference between “us” and “them”. Fair enough. It’s not a problem if you never find yourself pushing those boundaries – and fortunately those boundaries are usually defined very loosely.

I joined the scrum discussion group and even contributed to the discussion from time to time in some small way. There were lively debates that went on and I found the discussion, while often pedantic, was generally entertaining and occasionally enlightening. Then one day a group of people were formally cast out of the discussion group by the moderator, Ken Schwaber. They were people whom I respected, but they had an apparently annoying habit of calling things into question – especially scrum itself. Apparently Ken got frustrated with this, and kicked them out of the group. To me, this really came down to intolerance. While there was a reconciliation that took place and some of the people where permitted to return to the group, I quit the discussion group. I was offended by what I had seen. I didn’t want to belong to any group where I could be rejected for asking the wrong question. Ultimately it was a minor thing for the group, but I discovered I had a sensitivity to that sort of behavior that I hadn’t realized before.

Around that time I worked for a body shop/project outsourcing/consultancy that prided itself on its adoption of scrum. As with many groups, they went through a period of orthodoxy and testing for conformance. It seems to be part of the agile adoption life cycle. It doesn’t matter what the process is. It could be scrum, XP, or Lean. At some point, the corporate enthusiasm rises to a level where people start to say, “We should ALL be doing this!” That usually leads to testing for conformance. It’s surprising the kinds of things that people will test you on to see if you are agile or not. The questions include, but are not limited to: practices, ideology, technology, behavior, values. Nothing is out of bounds. If you’ve ever experienced this you know exactly what I’m talking about. People put together assessments in order to test your conformance to the principles of your process.  Then, to quote Project Runway, you are either “in” or “You are out!”

I went along with this for a while, but I found myself getting increasingly upset with the whole assessment thing. It was a difficult time for me for a lot of reasons. I remember stating my fear explicitly once, “What if they find out that I’m not Agile enough?” I know it’s a ridiculous question, but it’s how I felt at the time. I recall having a meeting with the folks who were in charge of compliance where I got very emotional – perhaps unreasonably so, as I tried to express how damaging I felt these kinds of assessments were. I was never assessed as not agile enough, but then again I did eventually get laid off. Hmmm…

I keep bumping into this issue over an over again with the scrum community. I find myself questioning things – the value of scrum, the value of what we are trying to do in the agile community. I write blogs like this one where I express my reservations and doubts openly and honestly. Having been fairly successful with agile projects over the years, I decided to try and apply to become a certified scrum coach. No dice. I couldn’t meet the standards for that group. I didn’t agree with the assessment, but I found that the process was very opaque and there was no allowance for discussion or debate on the assessment. No response at all. I was simply shut out. So I was done. Come back next year. With better answers next time.

For some reason I just couldn’t summon the energy to go through more of that. I decided that I didn’t want to be part of a group that wasn’t willing to take the time to genuinely engage with me. These days anybody can put the words, “Agile Coach” on their business card and people don’t ask a lot of probing questions. So I really don’t need the certification. Furthermore, I’m not sure that I want to constrain myself to just coaching scrum. I’m fascinated by a lot of other processes that have nothing to do with scrum. Some are even counter to scrum. So I found myself rejected by a part of the scrum community and questioning my motivations for being a part of that community in the first place.

So recently my certified scrum professional certification expired. I went to the website and discovered that if you have been a CSP for 2 years, you must re-apply for the certification AND pay $250 for the privilege. Now really it’s just a formality (and money), so why should I be concerned? I’m having a very hard time with this decision. I have a lot of very good friends in the scrum community, but I’m honestly getting pretty tired of the BS. I really don’t want to be assessed again. I want to be part of a community that accepts me for who I am. I’m tired of fearing rejection. I’m tired of paying money for the privilege. I really don’t believe that it serves to improve the community. Maybe it’s time that I just moved on. Something tells me that as a leader and a follower, my world would be a whole lot richer if I spent a little time away from the narrow pedagogical confines of scrum. It could be a mistake. This could be the dumbest thing I’ve written in a long time. Call it Shu Ha Ri. I’m going Ha for a while. Ha.

The Agile Meatgrinder

Have you ever looked at a really high functioning team and asked yourself, “Hmmm…I wonder what they would look like if they were sausage?”

Yeah, me too.

So, since all of us capital ‘A’ Agile types are really just wannabe chefs (and interior decorators) I would like to offer up a recipe for making a complete hash out of an agile team. I prefer a three stage approach that almost always works:

1) A pinch of Multi-tasking
2) A dash of Failing to address impediments
3) And a hefty helping of Increasing pressure on delivery

These three strategies are the secret ingredients to transforming a normally healthy team into a big steaming pile of chorizo. So let’s get started!

First things first: Multi-tasking (tenderize)

Multi-tasking has been much maligned as a hindrance to a well functioning team. The beautiful thing about multi-tasking is that the damage you do to the team is mostly invisible. When a team is multi-tasking, there are no idle hands. Everyone is working away like mad. How can that be anything but good? Nothing is quite as satisfying as the loud “Crunch!” a team makes when it hits the productivity wall head first.

Impediments not addressed/resolved (stew)

Even with multi tasking, I’ve noticed that teams can keep a fairly high morale (at least until the “crunch” hits). Especially tough teams need to be softened up a bit – the best strategy to wear them down is to fail to resolve impediments. Keep track of Impediments. Make them visible to the team – you want to remind them every day that the things that are holding them up are not being addressed. At all. There’s nothing like making it clear to a team that you, and the rest of your organization, really can’t help them in any meaningful way to achieve their objectives. If you listen very closely you can actually hear a team start to fry. I smell bacon!

Increasing Pressure on Delivery (bake at 425)

Now, in my experience, all the really great recipes for disaster call for the use of a pressure cooker. Here is where we really stir things up and heap on the pressure. There are 3 key strategies that I use to turn a team that is spinning like a top into the ultra high speed centrifuge from hell:

1) More metrics – on agile teams we like to call this “transparency!”
2) Focus on “productivity” over removing identified obstacles (see Impediments not addressed above)
3) More status reporting – even more “transparency!”

Agile teams are total suckers for this “transparency” thing. You simply crank up the metrics that the team is required to report, increase the frequency that the team has to report status, and then tell them they aren’t productive enough. And you do it all in the name of “transparency”. Be sure to remind them of that from time to time. Agile teams fall for this ruse like cattle in a meat packing plant.

Feeds 7 plus or minus 2.

What to do if you’re an A**hole

Bill Cosby has a great bit in one of his comedy routines where he talks about getting stoned. He’s having a conversation with a pot head that goes like this (I paraphrase from a rather unreliable memory here…),

“Why do you smoke Marijuana?”
“Dude, because it intensifies your personality!”
“What if you’re an asshole?”

Sometimes I feel like I’m having that conversation with some of the teams that I coach. It goes something like this,

“Why are you doing (name a particular practice)?”
“Because it makes us more agile!”
“What if you’re…”

Seriously folks, sometimes we need to be asked this question.

First Class Impediments

About a year ago I put together a terrific tutorial on finding and managing impediments. It was something that I felt strangely passionate about. But I must confess that focusing on impediments felt a little weird. I’d refer to it as my “silly impediments presentation”. You don’t see many talks at major Agile conferences that discuss impediments. After all who really takes impediments seriously anyway?

Apparently, really good project leaders do.

In fact, it’s arguably the most important thing that good leaders do. Go ask your team what a good scrum master does. Dollars to donuts, I bet you get “remove impediments” for an answer every time. So I guess impediments are pretty important, perhaps equally important to some of the more glamorous subjects in the agile books (you know: planning, retrospectives, etc.). So it’s time that we made impediments a first class member of the project management conversation. After all, planning, stand-ups, and retrospectives won’t do much for you if you neglect impediments. You just end up stuck and reflecting on that fact.