Embrace Your Inner Mad Scientist

Recently I’ve come to value experiments. I value them so much, it seems all I’m doing is experimenting.

That’s no coincidence: In an agile environment, a start-up company, or new research, we’re up to our armpits in uncertainty. We try to control it in different ways, but the fact is, unless things are clear cut, we have no idea how our decisions will play out. You can take this in different ways. One way is to ride the flow, see what comes. Or you can create check points.

An experiment is something you’re starting. You decide on what you want to check, set some initial conditions (those that you can control) and off you go. You can’t guarantee any result, but you can decide when the experiment ends.

If you take this view point, almost everything can look like an experiment.

The new feature you want everyone to love. Will it work? Will everybody love it? What do you do? Experiment.

You’re introducing TDD. Will the team work with you or against you? Don’t know? Experiment.

Simple, isn’t it?

Read the small print

Not all experiments succeed. Remember that “no guarantee”? Things can really blow up. Let’s face it, they mostly do.

When things blow up, it usually means the experiment is over. This is where you declare defeat.

And start a new experiment.

This is the difference between being swept by the river of uncertainty and making course corrections.

As a change agent, what you’re doing is trying things out. Sometimes they work, and you move on to the next thing.

Sometimes they don’t.

Then you move on to the next thing.

Just Shut Up

I have a big mouth. The kind that doesn’t shut up, especially when it needs to.

I thought this was a development in my adult life. Alas, no. Recently I went to my first school reunion, and the people confirmed I had this situation back then too.

Usually it’s not a problem, and if it is, it’s a problem for me. My mouth is big enough for at least my two feet.

It seemed like an advantage. Early in my career I was the answer man. I had all the answers (mostly the right ones, you’ll be surprised). As I’ve become a team lead and a manager, I’ve continued the tradition. My team came to me, and I’ve given them the answers. I’d tell them what to do and how to do it, and that looked the effective and efficient way to manage.

Then I’ve discovered that silence has its rewards. It can lead to more creative solutions, independence among the team and productivity. The benefits outweigh saying anything.

Asking the team “How do you think we can solve this?” (even if I know the “right” answer), can lead to other people offering suggestions I didn’t think of. They might bring up reasons why my solution is wrong, without me even saying it. The discussion does not only raise ideas, but since people own their suggestions, they also back them up with commitments.

And there’s more. I’m referring to the “Ask, don’t tell” idea, discussed in a recent Manager-Tool podcast. The podcast discussed asking team members to do tasks, even saying please (gasp!), rather then telling them to do the tasks.

I’ve caught myself doing that too. It’s part of the big mouth thing.

We think of self-organizing teams as a democracy, where everyone’s equal. This is not so. Even in self-organizing teams, there are more dominant people. We recognize them by them making decisions, sometimes for other people. They seem to know more than other people (note the word “seem”). They influence the team more than other team members. And just there, there’s a place for improvement.

If you’re like me (and you probably already know) the next time a question is raised, wait. Bite your tongue (it hurts, I know).

Ask questions instead of answering.

You’ll be surprised. You might discover that you’ll get more by saying less.

Re-Pair Programming

When asked:”What’s the best thing I can do right now to improve my code quality” I always answer: code reviews. A code review is the best bug preventer out there. And even more, I like its older brother better: Pair programming.

Because if a code review finds bugs after the fact, working in pairs finds bugs as they enter the code. The discussion on design options usually results in a better design, and there are more people who can support the code, because not only two people have seen that code, but also discussed it.

Most of my life I didn’t pair program, apart from doing it informally, like working on a bug. At Typemock, I did it most of the time, with no special methodology. Didn’t have a pilot or navigator. Just working together on different problems.

As I’ve gone back to pairing recently, I found it different than before. Apparently I’m more alert to how the process works, whereas before I’ve just gone along for the ride.

So here are a few things I’ve noticed this time around. It was mostly as a pair to an expert, and a few times leading the pair

  • Atmosphere. Going into a session, you’ll feel how it’s going. It’s based on how attentive you are, how is your partner is, how much both of you know the problem domain and code. How you get on from here relies on your starting point.
  • Patience. This coming from someone who doesn’t have much of it. I don’t recall if it was this way a few years ago, but man, I needed to work hard at it. When I was the expert, I needed to explain in length without making it sounds like I’m bored.
  • Nodding works. When I wasn’t the expert, taking on the role of a rubber duck, coaxing the driver to explain the problem and solution, provided a solution many times. Of course, that required me to shut up, which wasn’t easy.
  • Safe silence. When I wasn’t the expert, I found myself weighing in if to ask a question or not, fearing it might sound stupid. Silence offers safety. I coerced myself to ask some questions, qualifying it with “I know it maybe a stupid question, but…”. Results varied: Sometimes it pushed the discussion forward, sometimes got a “yes, it is a stupid question” look.
  • Attitude matters. Mine of course, but how the partner behaves has much to do with the success of the process. For example, when working with an expert, I’ve noticed phrases and gestures that made me think I was slowing the process at times. I had to fight this off in my head, or shut down. When I was the expert (or more knowledgeable from the partner) I had to resist conveying the same feeling. Both were hard.
  • Partners matter. From the soak-everything-in to the know-it-all, there are no perfect partners. Some are more compatible than others. You may not have a choice with whom to pair, but there’s a learning and growing opportunity with all.
  • Negotiations. Collaboration, even in this level, is about give and take. Based on the atmosphere you’ll decide when to push topics, from naming to what to test. Your partner may agree, disagree or raise you five. Be ready to accept losses on the way to completing the task.
  • Undebated truth. When leading a pair with a junior person, many things I said sounded like a fact. Non-debatable fact, no reason to discuss, just plain truth. This is really dangerous. We should encourage questions, embrace peeking and poking in our vision. Still, I found it hard to stop moving forward based on my assumptions.

Pair programming isn’t just a development practice. It’s skill, which we can improve and reflect on to choose our way. It’s still worth the time spent, just like unit testing. And like unit testing  - It requires a lot of discipline. Discipline to ask when it’s awkward, to stop running when feeling sure and to give up sometimes, to win other battles.

What Does A Self-Organizing Team Has To Do with Leadership?

Let’s say we’ve “conquered agile”, and the prophecy came true: we have a self-organizing team.

How does leadership fit into this?

What does a leader do in a self-organizing team?

Influence. Leadership comes in many shapes and colors. There’ll be the technical leaders. The experts about technology and or process. There’ll be  social-political leaders. We’ll ask them who to involve in discussions, and who will get upset because we didn’t. And there’ll be the visionaries, who will tell us where we need to go when we’re lost.

Does a self-organizing team need a leader?

Wrong question. We’ll see leaders emerge, whether we want to or not. It’s part of the self-organizing thing. So there will be one or more leaders with different types of influence. We can’t know in advance who will be the leaders, and we can’t really direct it.

Can we grow leaders to be managers?

Good communicators have a good chance to lead. Experts can be the wise men and women to find answers and innovate with whole teams.

But the truth is: We don’t really know.

What we can identify is potential. But we don’t know about the potential fulfillment. When leaders emerge,  we promote them or move them to other teams, expecting their leadership to evolve in the same way. But teams, self-organizing or not, will evolve differently because they have different people. Teams are complex system, so we don’t really know what will happen. We can try the influence the systems, but expect some surprises. We don’t know the outcome.

So what’s a manager to do?

First, we need to understand that self-organizing teams are more effective than teams under command-and-control pyramids. As managers, we need to step back, and let the team gain autonomy to get more effective.

When leaders emerge, and we’re thinking “promotion”, we need to prepare them. Because to become effective managers, they’ll need to know about how to evolve self-organizing teams by themselves. We’ll need to tell them all about complexity and uncertainty. About how to influence from outside by taking a step back.

Most organizations don’t teach that since the idea of self organized teams are not encouraged.

But if you want to change the organization, start by creating effective teams. Identify potential leaders, prepare them for promotion by teaching them, and then help them grow their teams to be effective.

And maybe someday, we won’t need “managers”.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More