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)


Tiny Bites

One of my takeaways from the Agile Conference last year was the need to learn how to divide work into as small a chunks as possible. In Alistair Cockburn’s Elephant Carpaccio tutorial, he presented an interesting statistic: programmers using Agile software development techniques commit code to their revision control systems ten times more frequently than programmers who don’t. That’s not because they work ten times faster; it’s because they see how to slice their work into pieces that are ten times thinner.

As I’ve been using these slicing techniques more and more in the last year, I have felt like the frequency of my commits has gone up. I did an experiment last week where I measured the time between my source control commits, just to see how big a chunk of work I was biting off each time. It turned out that over the course of a three-hour programming task, which represented adding a small new feature to the same code base I was working on yesterday, I was committing my code to the repository an average of every twenty-five minutes. The variation wasn’t high either; that was just the natural rhythm I fell into — and it felt good. I’d do the Red-Green-Refactor loop a few times until it felt like I had a substantial enough milestone to check in, commit it, and then take on the next chunk. I was developing this code in parallel to the existing code, so I kept everything working at all times. It was only in that last chunk that I switched over the main code path to using the new functionality I’d developed, and because of the way I’d put it together, the switch was easy to make. It was one of the most satisfying programming experiences I’ve had.

Which makes it particularly ironic that I utterly failed to apply these techniques yesterday, resulting in things going bad. But I’ll save that story for tomorrow.


Fitness: Rest day
Sun, Moon, and Stars: 305 words, 390 seven-day average, 287 average, 53026 total, 26 past the goal for the week; 7-day streak

Work Worth Doing

Today was the payoff.

For at least a week, several of my teammates and I have been struggling to get part of our new system test infrastructure to work. It’s been coming along slowly, but at the end of last week we hit a problem we just couldn’t figure out. We were getting a bizarre networking error when we tried to run the system through the framework, but that didn’t appear at all when we tried it with the remote GUI tool. Finally, last night we sent an email describing the problem to our sister team in Switzerland, hoping they could help us debug the problem.

This morning at our Scrum of Scrums meeting, we brought it up in the “what problems are we having that we could use some help from the other teams?” section. Somebody suggested something we could try, but it seemed to me like he didn’t fully understand what we were doing. So I suggested we discuss it further in the problem solving part of the meeting. We agreed, and in about five minutes we laid out what problem we were trying to solve. The response was “Oh, the GUI doesn’t use that code anymore. You should use the HTTP request method.” Five minutes after that, he’d shown us what we needed to do, and five minutes after that we had a prototype working. By the end of the day, the problem we had no idea how to solve was fixed.

So today was the payoff of the work we’ve done over the last year to open up communication and enable collaboration between our developers, spread across the world from Wisconsin to India, from Switzerland to California. That’s actually not true: it’s just the most recent of many payoffs. It’s hard work to keep the information flowing between the teams. And it would be easier if we we’re all co-located. But given that we’re distributed, the cost of doing that work is outweighed by its benefits. Today was just the latest reminder of that.


Fitness: Ran 3.5 miles
Sun, Moon, and Stars: 0 words, 400 seven-day average, 277 average, 42949 total, 551 to go for the week

I Need to be More Zen

One my problems at work is that I know too much.

I’ve said before that I’m not the world’s strongest software developer. One of the attractions that a facilitative role like Scrum Master or Agile Coach has for me is that it lets me help people who are better developers than me become even better. When I focus on process and detach from outcomes, I really can help the team get more for itself.

The problem is that recently I’ve been working in areas where I am one of the more knowledgeable people on team. When I’m a subject matter expert at the same time I’m trying to be a process owner, I have hard time letting of my desire for particular results. That can compromise my neutrality as a facilitator, which is never good.

This week, for example, I got very frustrated with a team member for doing something different than we had decided.1 I was concerned with what I saw as a breach of our established procedures, but I think responded more strongly than I would have otherwise because I disagreed with the substance of the changes. I tried to stay neutral by only bringing up the procedural objection, but I don’t think that worked. Maybe I should have disclosed my technical objections as well. It’s still not clear to me what the right thing to do was.

This is something I’ve struggled with a lot at work, as I’ve been asked to wear technical contributor and coaching hats. I’m starting to see it change as the team matures, and I’ve been able to deliberately let other members overtake my knowledge in particular areas. That feels weird to do at times, but in the long run I think it’s the best choice for the team and for me.

Either way, it’s a lot easier to be a facilitator when I genuinely know nothing about what we’re dealing with.


Fitness: Ran 5 miles
Sun, Moon, and Stars: 534 words, 201 seven-day average, 261 average, 35499 total, 501 go for the week; 3-day streak

1 I realized today, while working through The Facilitator’s Guide to Participatory Decision-Making, that this may have been caused by a lack of clear decision rules, which meant that I thought we had moved to action while he thought we were still deciding.


Harder and Better

Today was about practicing what I preach.

For the last several months I’ve been telling the team that we need to take our time and do things well. We’ve dug a pretty deep hole by letting ourselves be pushed beyond a reasonable speed. Along the way we’ve accumulated a fair quantity of technical debt, and I’ve been encouraging people to stop rushing through things and to fix problems as we find them.

Today was, of course, the day were I was tempted to do the opposite. Half of our team was out today, which meant I needed to take up some of the technical slack. We’re right at the end of the sprint, so I was looking to make progress as quickly as possible. I was plowing through things left and right this morning. Then, just after lunch, it happened.

As I was trying to port some of our test code to one of our other supported operating systems, I noticed a problem. Because of some variations in hardware, the test needed to have different settings based on which board it was running on. Unfortunately we didn’t have a way of detecting that. I thought about using the slower but safer settings for both. We could just come back later and clean it up. Then I remembered what I’ve been telling the team: Later never comes.

I came out of the afternoon with cleaner code, a stronger feeling that warnings are really errors you haven’t met, and better understanding of why we need to improve our build cycle times. And, most importantly, a deeper appreciation for why the things we’re trying to do are both hard and worthwhile.


I Think The Garage Is Next

Today I finished a home-improvement project I started two years ago. It was a humbling reminder of why work in progress is bad.

About three years ago, I read Mary and Tom Poppendieck’s Lean Software Development, which gave me my first look at lean systems thinking. By examining sources of waste in software processes, it fundamentally changed the way I think about work. One of those sources is partially completed work, or as it’s commonly known, work in progress (WIP). Some Agile methods, such as Kanban, attack this source of waste by establishing explicit limits on the amount of WIP you’re allowed to have at any one time. Even those that don’t, like Scrum, still focus on minimizing WIP by forcing you to drive things to done a regular intervals. In one form or another, this mindset has permeated my professional thinking for several years.

Why is WIP bad? Several reasons. First, there’s an analogy to be made to inventory in manufacturing. Just as inventory is money you’ve spent to acquire goods you haven’t yet sold, WIP is effort that you’ve exerted but haven’t yet realized the value of. Second, it’s hard to tell if you’re doing the right thing when you have WIP. Partially complete work is hard to get feedback on, especially if the person doing the work isn’t the person who will be using the final result. Third, higher levels of WIP increase the likelihood of task-switching, which is another source of waste. And perhaps most insidiously, having work in progress means you have something hanging over you. The psychological effect of WIP can be severe.1

Which brings me back to my home-improvement project. When Gwen and I bought our house, we remodeled the upstairs kitchenette into a bar by pulling out the old cabinets, installing a new countertop, and putting in an under-counter fridge. It was largely done, with two notable exceptions: the sink had a clog a long way down the pipe — leading to a slow drain — and I hadn’t installed the toe kicks under the cabinets. The bar was mostly usable, but it was hard to clean up because of the sink problem and it didn’t look quite right because of the toe kicks. The former was annoying me, and latter was annoying Gwen. The combination of the two led me to do something about it.

A few weeks back I picked out a weekend to drive this to done. This morning, a plumber showed up and cleared out the clog. This afternoon, I finished ripping the boards down to the correct width for the toe kicks, applied the laminate strips, and attached them to the cabinet legs. The result of a few hours of effort: Work no longer in progress. Now I can toss out the extra supplies, pack up the tools, and move on to the next project.

Over the last six months, I’ve made conscious decisions to reduce the number of projects I’m working on at a time. I’ve seen that I’m happier with the results of my work when I do this, and I’m happier overall. It’s gone well enough that I’m now going back and seeing what projects I’ve left in half-finished states over the last few years. My goal is to drive all of them to done by the end of the year. The bar was the first step.

Now it’s time for celebratory cocktail. Then on to the next thing.

1 In fact, my favorite Scrum definition of done is “done means you don’t have to think about it anymore.”