This September 16th we are going to hold a brand new conference in Seattle. It’s a conference dedicated to Agile Management. It’s for managers, executives, coaches, consultants and leaders (lots of folks!) who use agile practices and techniques to help organizations find a better way of working. If you read this blog, that’s probably you. This conference is intended to create a place to have conversations with leading agile practitioners, share stories, and explore new ideas.

The Vision

When you arrive, the first thing that strikes you is the sense of history in the building. The next thing that stands out is the circle of chairs. They’re right in the middle of the space and they seem to draw you in.

People start to filter in, some grabbing a cup of coffee and a pastry. Some chatting and exploring the space. Soon, everyone gathers at the chairs and grabs a seat. Things get kicked off with a short keynote from Ray Arell. It’s really just a story. A fireside chat. Sharing an experience – sharing the theme for the day.

Shortly afterward, the open space bulletin board opens and people add their topics. The marketplace opens and the conference starts in earnest.

The marketplace wall is the focal point for a series of conversations. It starts off in the morning being completely blank. They started off with a set of proposed ideas – each idea written on a colored thought bubble. The thought bubbles were taped to the wall. Throughout the day, people connect the bubbles using yarn. Or they add new bubbles. Runners keep the wall up to date, moving back and forth from ongoing conversations.

At the end of the day there is a synthesis. The participants use a single sheet of flip chart paper to summarize their favorite ideas. Working groups form, emails are shared, agendas proposed, and meeting times set.

In the evening, there is a closing, a retrospective, and appetizers and drinks.

That’s not a bad vision, but all of that just captures the superficial stuff. The stuff that we can control. The rest? Well, that’s the “open” part of open space. I don’t know what people will bring. What I do know is it works. I never fail to be surprised.

I recently read Rose and Benjamin Zander’s book The Art of Possibility: Transforming Professional and Personal Life and I strongly recommend it. To me it was a book full of stories about mindset management, all primarily set in the wonderful context of music. Much of the book described techniques for moving from a mindset of bankruptcy to a mindset of abundance.

That’s something that I can relate to in my current role. There are times when I find myself trapped in that mindset of bankruptcy. The narrative in my head goes something like this: None of the teams I work with is doing what I hoped they would. We’re not agile enough. We’re not innovative enough. Our culture is all wrong. We can’t get there from here. We suck.

That’s the mindset of bankruptcy talking. There’s never enough. We’re never good enough. It’s a pretty bleak place. I know I’m not alone in living there from time to time. I work with people who come to me with this narrative all the time. What do I tell them?

Well, first of all, I have to check in with myself and see where I’m at. If I’m in the same place as they are, then this conversation isn’t likely to go well. The best I can usually do in that case is to commiserate with them.

But there are times when you are in the place abundance. There is another perspective that allows a much different interpretation for the same set of circumstances. I find that talking with folks from a variety of different backgrounds helps. They’re the ones who will look at me and say, “Wow! You guys are awesome! I hope we can get there one day!” At first my reaction is to deny what they are saying. We aren’t that good. You don’t really get it. But then sooner or later it dawns on me that although we have many things to improve on, we also have managed to achieve amazing things along the way. Things that we now take for granted.

The difference between those two mindsets is that one has room for new opportunity and the other leaves little room for any opportunity at all. I loved their expression when something fails, “How fascinating!” Using a phrase like that suggests curiosity and an openness to exploration. I love it.

I don’t know if I have the kind of temperament that would enable me to live in this mindset full time. But I sure would like to visit it more often and maybe even share the trip with a friend.

So there you are, wrapping up another successful release planning session. Sprints are all laid out for the entire release. All the user stories you can think of have been defined. All the daunting challenges laid down. Compromises have been made. Dates committed to. Everyone contributed to the planning effort fully.

So why isn’t everyone happy? Let’s check in with the product owner: The product owner looks like somebody ran over his puppy. The team? They won’t make eye contact and they’re flinching like they’ve just spent hours playing Russian roulette. What’s up? Well, here’s the dynamic that typically plays out:

The product owner has some fantasy of what they think they will get delivered as part of the release. This fantasy has absolutely no basis in reality, it just reflects the product owner’s hopes for what he/she thinks they can get out of the team (it’s just human nature). This is inevitably far beyond what the team is actually capable of. My rule of thumb? A team is typically capable of delivering about 1/3 of what a product owner asks for in a release. That’s not based on any metrics, its just an observation. However, more often than not, it seems to play out that way.

The team is immediately confronted with a mountain of work they can’t possibly achieve in the time allotted – even under the most optimistic circumstances. It’s their job to shatter the dreams of the product owner. Of course, strangling dreams is hard work. Naturally enough, the product owner doesn’t give up easy. They fight tooth and nail to retain any semblance of their dream.

After an hour, perhaps two, maybe even three or four (shudder), the battle is over.

I’m going to go out on a limb here and speculate that this is no one’s idea of a positive dynamic. But it seems to happen pretty often with agile projects. It sure doesn’t look like much fun. I’m pretty sure this isn’t in the Agile Manifesto. So how do we avoid this kind of trauma?

The product owner needs to be a central part of the team. They need to live with the team, be passionate about the product, and witness to what a team does daily. Fail to engage in any of this and a product owner loses touch with the work the team does and loses the ability to gauge their capabilities. Doing all of this is hard. There’s a reason that the product owner is the toughest job in Scrum.

The team needs to embrace their product owner as an equal member of the team. You have to let them in. Work together. Let go of the roles and focus on the work.

Prepare for the release planning in advance. There is no reason for it to be a rude surprise. Spend time together grooming the backlog together. As a team.

Don’t cave to pressure from upper management. Behind every product owner is a slavering business with an insatiable desire for product. Ooh, did I just write that?

Recently I’ve been challenged by the question, “Can you change culture?” I think this is pretty common for folks who work in large organizations. The question of culture and how it blocks or allows us to get things done is a thorny one. There seem to be two opposing schools of thought in the agile community on the subject of culture:

You can’t change culture, you can only adapt to it (customize your process to fit)

You can change culture (through influence, good looks, and the right practices)

Of course, perhaps the first question is, “What is this culture thing anyway?” Most definitions of culture are terribly vague and in my opinion not especially useful (although, couched in the delightfully hand-wavy terms of corporate sociology, they usually sound very smart). Just for giggles, here are some definitions:

Culture is the accepted norms of behavior for a group

Culture is the collection of social contracts that a group depends on

Culture is how we treat each other

Culture = people

I forget where I saw that last definition (Tobias Mayer?), but it’s probably my favorite of the bunch. You see often culture is used in conversation to hide or excuse problems with people. It’s kind of like referring to employees as “resources” (Ooh! Now I can be that irritating agile guy who corrects people’s terminology! A word to the wise: Don’t be that guy). So where was I? Oh yeah, culture. So here’s the deal, I don’t like the term culture because it’s just too damn vague. Often times I get a lot more clarity if I use more specific terms to describe the problem. For example:

Our culture won’t permit us to do that = Manager X won’t permit us to do that

Our culture only supports hierarchical decision making = Bob likes to make all the decisions

Once I take the time to replace culture with more specific terms (Who, What, Where, When, Why), I usually find that the problem feels more manageable to me. More human and less onerous. On the one hand, “Our culture” is vague and hard to put strategy around. On the other, influencing Manager X is a simple exercise in winning friends and influencing people. That’s something I know how to do. People I can work with. Culture…not so much.

So if you accept this definition of culture (culture = people), then your ability to change the culture directly depends on your ability to influence people. That’s Dale Carnegie stuff. It’s not easy, but it can be done – one person at a time. When you are in a small company, that’s not too daunting a challenge – win a handful of people over and you are done. However, in a large company, it’s quite a different matter. In a large company you have to win over hundreds or even (heaven forbid) thousands. That’s a very different challenge – and it’s an order of manure…uh…magnitude more difficult. It can be done, but it’s a long term challenge that may take years – and while some strategies you will use with larger groups are the same as for small groups, often they can be very different. If you are accustomed to trying to change the culture in small companies, you almost have to learn a completely new language in order to try and change the culture at large companies.

But seriously, can you REALLY change culture in big companies? One way to answer this question is to look for examples of successful culture change within large corporations. There are one or two that I can think of:

Richard Semler, SEMCO (As described in the book, “Maverick”)

James Collins, “Good to Great” (A series of stories of dramatic corporate change)

If you accept these stories as true, then the answer must be that culture change can indeed happen. But perhaps you are an inveterate cynic (like me) and don’t believe everything you read in books. Maybe culture change is just something that people with extraordinary power can achieve (like CEOs). Then what hope do those of us who exist much lower down in the corporate hierarchy have? Two thoughts:

Sometimes we have to accept that our sphere of influence is limited. Those limitations are things that are very real like geography. You may only be able to influence folks that you work with in your particular office (which makes a lot of sense). Influencing the rest of the organization is going to be much harder. This has nothing to do with culture and everything to do with constraints. Start small, gather your wins, and grow.

You can just wait. Bide your time. Sometimes you have to wait for the right opportunity. How long should you wait? I don’t know. There is an element of patience when dealing with culture change. You need a lot of patience. Focus, prioritize, and be ready. There’s nothing wrong with that approach.

OK Tom, what if I still don’t buy it. My company is HUGE and there is just no way that I can influence these clowns…er…people. No matter what happens, once an organization gets above a certain number (perhaps the Dunbar number) then it becomes extremely difficult to change. So difficult in fact, that it’s just not worth fighting. If that really is the case (and in many cases it just may be), there really are two approaches:

It may be that there are kinds of change that will never be accepted within some organizations. However, usually, that is a relatively small set of invariants. There usually still remains a broad spectrum of change that can be introduced successfully. Just stay away from the hot buttons. Does it really matter that you introduce every single one of the 12 XP practices? Or would it be enough just to introduce a few (there is still some benefit gained). Can you bring change in small amounts rather than a huge batch? There is plenty of room for creativity in this sort of culture change.

In the end, even after all this, you may come to the conclusion that you can’t change the culture in big organizations. Maybe it’s just too hard. Perhaps you just don’t like Dale Carnegie. I don’t know. That may just be the way it is. If that ends up being the case for you, then saddle up Rozinante. Grab Sancho, and go find some more giants to tilt at. The world is full of them.

In this wonderful blog post, You Are The Impediment, Mike Cottmeyer argues that there are three different levels of impediment management required of a good scrum master/team leader:

The Tracker

The Remover

The Anticipator

He characterizes this as a sort of competence hierarchy for agile managers: Tracking being the minimum one could do, Anticipating being the desirable thing to do. I strongly agree. I see it this way:

Tracking = History

Removing = Managing/Problem Solving

Anticipating = Risk Management

Each level has a valuable skill set associated with it.

Having a history, whether it is a history of sprint velocity, a history of stories, or a history of impediments, is essential to creating the necessary level of information for the team to learn well. Like they say, those who ignore history are doomed to repeat it.

Removing impediments is really about problem solving. Problem solving is all about root cause analysis, building hypothesis, and tracking the results of experiments. It’s common to see teams rush at solutions without taking the time to understand the problem well. We need to get better at using problem solving techniques to help us resolve impediments.

Anticipating impediments that have yet to happen is also known as risk management. Risk management is poorly understood in the agile community. Look for it in books regarding Scrum and XP and you won’t find any mention of it at all. Fortunately, there are some great books on risk management like Waltzing with Bears, that should be required reading for all team leaders.

A good leader needs to cultivate all three skill sets in order to maximize their team’s chances for success.