Who am I?

I’m an Agilist, a former software engineer, a gamer, an improviser, a podcaster emeritus, and a wine lover. Learn more.

Currently Consuming
  • The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    by Eric Ries
  • The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    by Daniel Coyle
  • Alexander Hamilton
    Alexander Hamilton
    by Ron Chernow

Paul Tevis

Entries in lean & agile (23)

Tuesday
Nov222011

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.

Friday
Nov112011

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)
Saturday
Oct292011

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.




Update

Fitness: Rest day
Monday
Oct032011

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
Sunday
Oct022011

Biting Back

How much did forgetting to work in small increments screw me up on Friday? So much so that I did something I never do: I brought work home with me.

On Friday I needed to make a pretty serious architectural change in the way the new testing framework we’re developing does its error reporting so that I could add an important new report. The current structure created objects that couldn’t hold the new information we needed to pass along, but the real problem was that they were created at the wrong point in the process, after the errors I was looking to report had already occurred. So I need to make some object life-cycle changes, and I also had to contend with some pretty substantial technical debt. I’d been saying for about a week that the error reporting code was in the worse shape of any part of that code base, so I knew I was in for some real work. Friday I waded in, eager to get through it. Which is when my tired brain betrayed me, and I got stuck in the middle of a gigantic refactoring that I should have done as a long series of smaller refactoring. I realized I wasn’t going to get through it before the end of the day, and I didn’t want to make things worse, so I just stopped and brought it home with me.

The reason this turned into such an undertaking because of my failure to apply some of the new techniques I’ve adopted that have made programming fun for me again. Yes, I was using Test-Driven Development to build my replacement classes, setting up a unit test, creating the functionality required to make that test pass, and repeating every few minutes or so. And I was using my existing unit tests to protect myself while I was refactoring, extracting a new class here, renaming a method that, improving the design of the existing code to make it easier to slide in the new functionality I needed. But while I got these things right in the small, it was in the large that my discipline broke down. I started off working in (unintentionally) Pomodoro-sized blocks of time, but somewhere in the middle of the afternoon my disciple or focus gave out. And then I decided to switch the main code over to using something that wasn’t ready. And then the train wreck happened.

The way of out this, of course, was to go back to to what I was doing last week, to focus on incremental progress, to do one thing at a time and ignore the rest of the system until I was ready to tackle that next bit. So that’s what I did this weekend. First, I disabled all of the unit tests that were failing because of the changes I made so that I had clean slate to start with. Then I started picking leaf nodes in my dependency tree, turning their tests back on, and fixing them one at a time. Every twenty-five minutes, my timer would tell me to go do something else for a while. I kept a notecard handy to jot down “do this next” and “here’s how that object should work” notes for myself. Bit by bit, tests got re-enabled and features reappeared. And tonight, it all came back together. I can’t run it in the production environment because my VPN connection isn’t working, but I’ve tested it as throughly as I can without the right hardware. Tomorrow morning I’ll try it out at work. And while I didn’t like having to bring work home with me, at least I was smart enough to work on it in the right way.




Update

Fitness: Ran 5 miles
Sun, Moon, and Stars: 0 words, 355 seven-day average, 285 average, 53026 total, 26 past the goal for the week