Slicing It Thinner and Thinner

Part of my plan right now is to take all of the things I’ve decided are important and take at least one step forward on each of them every day. That means when I get busy, I don’t just drop two or three and work on the others. It means I have to find ways to take smaller steps so I can fit them all in. It’s challenging, but I’m finding it very satisfying. I can’t fit two half-hour tasks in but I have time for one? I have to find a way to make fifteen minutes on each of them worthwhile. And that’s really the trick: Learning to see how I can make tangible progress in smaller and smaller chunks of time.

I’m sure that my Agile experience has nothing at all to do with this…

Listen and Change

I should stop being surprised by how much my training as an actor and an improviser is useful beyond performance. Today’s epiphany was about feedback.

As an actor, you have to learn to take the note. This was hammered home to me during my sophomore year in college. After one of the last rehearsals before our play opened, the assistant director was giving me feedback on some lines I had fumbled. I was working through them, and in the process I was explaining why I’d messed them up. The director — my friend Rob — looked at me and said, “Paul. Take the note.” And I got it. The AD wasn’t asking me questions, so no answers were required. He was telling what I needed to fix, and my commentary on why I’d done what I had didn’t matter to that. I stopped talking, acknowledged the input, and next rehearsal I fixed it.

Sometimes, when we get feedback on something we’ve done, we don’t always want to take the note. When someone says, “Could it do this instead?” our instinct is to say that would be hard, or to say that they shouldn’t want it to do that, or any of many other variations on “no” that use more words than that. We don’t really listen to what they’re saying because we’ve become defensive and feel the need to justify what we’ve done. Fortunately, there’s way out of this.

First, take the note. Listen to what they’ve said and what concern it expresses. Why are they asking for this change to the feature? What’s at stake here for them? They wouldn’t bring it up if it didn’t matter to them, so your first job is to figure out what’s important here. It’s not about you at this point, so don’t just wait for your turn to talk — listen.

Then, do what a good improviser would do and ask “How could I say yes to this?” The reason you’re getting this feedback is because the person giving it to you perceives a gap between what is present and what is needed. Feedback systems exist to close that gap. That means that we have to be open to changing based on feedback. If not, we’re running in open-loop control.

Saying yes can be hard, of course. Maybe there’s a powerful reason why you can’t do exactly what they’re asking for. If so, see if you can propose an alternative that captures the essence of the concern they’re raised. Maybe you think what they’re asking for is a bad idea. In that case, you really need to figure out their perspective, because you probably don’t have the same understanding of the situation. Dig deeper into the reasons for their request, being open to the possibility that that there’s something you don’t know that makes their position make sense. And maybe you just don’t know how to get around what’s preventing you from giving them what they want. In that case, collaborate on a solution with them. Tell them, “I’d like to find a way to do that for you. I’ve got these problems that I’m not sure how to deal with. Can you help me work through them?” You may not always be able to get to yes together, but you have to try.

In order for feedback systems to work, we have to (a) listen to the information we’re getting, and (b) act on that information to change the situation. These can be hard things to do, but a simple place to start is by taking the note and considering how to to say yes.

In The Beginner's Mind There Are Many Possibilities...

I sent out this paper to my team at work this week. I already believed in a some of the ideas it, but the data and (even-to-me counterintuitive) results that it presents surprised me. I’m now very curious to see if we can replicate them, and at the very least, it’s got me thinking about we decide who works on what in a very different way.

Update

Fitness: 100 Ups (Minor) + 100 Hundred Pushups, Week 1, Day 2 (6-8-6-6-12)

Link Roundup for 29 October 2011

I’ve accumulated a backlog of software engineering-related links, so it’s time to burn some of them down.

• Elisabeth Hendrickson explains why everyone on the team needs to test.
• Rands challenges managers to take The Rands Test.
• Derrick Bailey illustrates Bob Martin’s SOLID development principles with motivational posters.
• Lyssa Adkins reminds coaches that it’s hardly ever “them.”
• Stephan Roock offers five tips for improving how your Scrum teams deal with impediments.

Update

Fitness: Rest day

Elephant Eaten

This morning I checked in the code I’d been working on over the weekend. I told one of my teammates I was nervous about it because I was doing in a single commit what I would have preferred to split across almost two dozen commits. Still, all of the unit tests were passing, and the bench test I’d done only turned up one problem (which was actually a pre-existing bug that I decided to fix). So I pulled the trigger.

And it worked the first time.

It’s almost like there’s something to this idea of working incrementally, creating loosely-coupled modules, testing them at their interfaces, and running all the tests all the time. I’m just hoping that next time it doesn’t take a complete breakdown of discipline to get me to remember that.

Update

Fitness: Ran 5 miles
Sun, Moon, and Stars: 479 words, 362 seven-day average, 286 average, 53505 total, 1485 to go for the week; 1-day streak