Who am I?

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

Currently Consuming
  • Lankhmar Book 1: Swords And Deviltry
    Lankhmar Book 1: Swords And Deviltry
    by Fritz Leiber
  • Born to Run: A Hidden Tribe, Superathletes, and the Greatest Race the World Has Never Seen (Vintage)
    Born to Run: A Hidden Tribe, Superathletes, and the Greatest Race the World Has Never Seen (Vintage)
    by Christopher McDougall
  • Test Driven Development: By Example
    Test Driven Development: By Example
    by Kent Beck
  • The Runner's Guide to the Meaning of Life [RUNNERS GT THE ME -OS]
    The Runner's Guide to the Meaning of Life [RUNNERS GT THE ME -OS]
    by n/a
  • Personal Kanban: Mapping Work | Navigating Life
    Personal Kanban: Mapping Work | Navigating Life
    by Jim Benson, Tonianne DeMaria Barry
« Limiting Work To Capacity, Part 2 | Main | Static Friction And Me »
Sunday
May022010

Limiting Work To Capacity, Part 1

One of my co-workers came into my office on Wednesday and told me he was worried about burning out. He’s been completely overloaded at work for the last year or so, and recently he’s been working 12-hour days to meet some deadlines. He’s been trying to unload some of the things on his plate by getting management to bring on some contractors, but as always there are money concerns. I told him, “This is going to sound funny, but part of the problem is that you’re working too hard.”

A while back I read a great article called “Saying No: A Short Course for Managers.”1 Its premise is that when you find yourself in a situation where you say yes to something even though you know it’s likely not to work out, you’re part of the problem. Among the insights from the article: when you don’t say, “we can’t do that,” you deny the group the opportunity for problem solving. Many of these sorts of issues are really organizational and structural problems. Making heroic efforts to get things done despite, say, an organizational tendency for taking on too many things at once hides the real problem. All you’re doing is treating the symptom, not the illness.

One of the things that I love about Scrum is how quickly it makes problems like this apparent.2 My boss and grand-boss had to report on the status of our project to the monthly company-wide project governance meeting. They said, “based on our measured rate of progess and the number of features left to do, we’ll be done sometime in 2012.” That got people’s attention (the project is supposed to be done by the end of this year), and the group gave us the go-ahead to pull more people onto the project and look at how to reduce the scope. Basically, we were able to limit work to capacity.

Despite the number of times I keep learning this lesson at work, I have a tendency to forget how important a sustainable pace is in all parts of my life. Some people have heard my “cycle of busy-ness” story before; basically, I tend to oscillate between being overcommitted (when I say “yes” to too many things) and under-enthused (when I drop all of my committments because I was overloaded). Part of the reason for those oscillations has been my inability to say “no” to things, but there’s more going on. I haven’t understood how much capacity I really have, so I haven’t been able to determine what a sustainable pace really is.

I decided it was time to figure that out. More on that in Part 2.



 

1 Which seems to have disappeared from the Internet, unfortunately.

2 As Angela Druckman said in the Scrum Master class I took: “Scrum will not solve your problems for you, but it will make obvious which ones you need to solve.”

Reader Comments (1)

Really good observations, my employer could learn a thing or two from this.

May 3, 2010 | Unregistered CommenterMicah

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>