This is the Way Scrum Ends

September 30, 2014

Processed with VSCOcam with x1 preset

This is the way the world ends
This is the way the world ends
This is the way the world ends
Not with a bang but a whimper.

– T.S. Eliot

Did you ever wonder if this is the future of Scrum? Will it eventually go out with a whimper? I think a lot of people fear this fate for everyone’s favorite framework. Go to a conference or follow your favorite luminary on Twitter and you hear a chorus of “That’s Scrumbut!”, “It’s FrAgile”, or “Welcome to Scrummerfall!” And maybe that’s the way it has to be. Perhaps all great new ideas eventually become diluted in a sea of mediocrity.

I think I hear a longing in some to fight such dissolution. To resist the forces of corporate entropy. Rather than try to fit in, they urge us to confront and overturn the system. You know, subvert the dominant paradigm? Confronting this dissonance is the difference between making a living and actually living.

I wonder if that’s the difference between those who “fire” their customers and those who stay and work within the system. Are those consultants who give up and declare, “These clowns aren’t ready for Scrum.” going out with a bang? And what about those who stay? Are they afraid to make the big moves and just content to fit in? Whimper. Or are they more subtle than that? Can you embrace your client and still change them? Perhaps the “bang” approach is quicker, and more decisive. And maybe, just maybe, remaining engaged is very, very hard, but yields results in the end.

I know, I know…why so bleak? Well, I feel this tension a lot in our weird little community. I’ve been on both sides of the engagements where a respected consultant has tossed their hands in the air and walked away from the engagement because “They just don’t get it.” or “They’re not ready yet.” And I’ve been that poor fool, laboring away within the system, living on a meager diet of optimism and the occasional conference, trying to make change happen. I won’t pretend to know which approach is right, or even when to use these strategies, but I think it would be worthwhile to understand this issue better.

Advertisements

Test Driven Organizational Change

September 11, 2014

change-20272_640

Let’s just say I was testing the bounds of society. I was just curious. –Jim Morrison (1943 – 1971)

I’ve been contemplating experimenting with some change, but I’m not really sure what is going to work and what won’t. In some ways that dilemma mirrors my coding style. Often when I embark on a project, I’m not entirely clear whether or not what I’m doing will work or not. I mean, I think it will work…but I’m really not absolutely positive. When I code…stuff happens.

I guess I could be accused of rushing into coding without taking care to fully think the problem through. But when I’m swept up in the moment, I want to run with the momentum I have. Call me impulsive. I admire others who have the self discipline to worry through the analysis before they get started, but that’s just not me.

That’s why Test Driven Development has been such a lifesaver for me. It forces me to think about what I’m trying to accomplish before I write the code. It gives my approach a little rudimentary discipline, rather than simply stampeding into the code. Moo.

The question is, can I use TDD to help with organizational change? What would that look like? In order to do TDD we have to start by asking ourselves what the expected outcome of this process or change is. In terms of team performance, that might mean a change among many different metrics (i.e. velocity, throughput, etc.). So first you set up the test: what would the desired outcome of the change be? More software? Happiness? Safety? Openness? Joy? Perhaps it is the absence of something?

Example Change: I want to bring more openness to new ideas to our work.

Next, what are the things that would indicate success? A change in the number of releases? A subjective rating of mood? Maybe a count of unsolicited ideas? Keeping a resistance index (a count of protests per session)? A count of positive/supportive statements. Basically we are looking for some kind of measure that might give us an indication that we are passing our test.

Example Test #1: I will count new ideas that come up in team meetings on a daily basis – If the count is greater than 10, then the test passes

 

Wacky thought: would it be possible to measure all behavior change in relation to changes in code? How would a subjective notion like enhanced social safety within the team be reflected in the code base? Whoa…I think I just bent something important in my head when I bumped into that last thought.

Of course, just like for code, you probably wouldn’t write just one test for any given change. Like code, change is complex, so we are going to be well advised to create multiple tests for any given single proposed effort.

Example Test #2: I will count the number of new ideas that get shot down daily – if the count is less than 3, then the test passes

Great, now we have some tests, what next? Well in TDD we run the tests first and verify that they all fail. Yes, Martha, all the tests are red. Good! Now, and only now are we ready to create change.

Example Test Run: Day one, test 1: result is 4 new ideas – test fails. test 2: the result is 4 – test fails. We are red.

So we put our change initiative into place. But wait – we must keep in mind rule #1 of test driven development: do only the very simplest thing to pass the test. What does that mean? Well if you want people to be happy, what’s the very simplest thing we could do? Would you go to HR and initiate some sort of peer reward system complete with executive buy-in and a roll out program with sensitivity training? Or…would you make a point each day of telling someone how much you genuinely appreciate working with them? Remember, rule #1: KEEP IT SIMPLE!

Example Change: Add a new rule to the team agreement – you can’t say “no” to a new idea.

Then we run the tests again. Where do we fail? Where do we pass? Now we might have some interesting information!

So, before I forget, there is one last thing we should do: refactor. Now we need to go back and take a look at those tests and see if we can improve them. We also look for ways to improve the changes we made. Maybe instead of telling people how much you appreciate them, you give them a hug instead.

Then just like in TDD, we go back to #1 and repeat.

Of course we can’t call this Test Driven Development because that name is already taken. Maybe we could call it Test Driven Change? TDC…Yeah, that could work. Let’s call it Test Driven Change – if I can get three people to do it, then we’ll call it a movement!

 


Culture Club

August 6, 2014

pablo-picasso-don-quixote

 

 

 

 

 

 

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:

  1. You can’t change culture, you can only adapt to it (customize your process to fit)
  2. 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:

  1. Richard Semler, SEMCO (As described in the book, “Maverick”)
  2. 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:

  1. 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.
  2. 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.