Loading ...
Sorry, an error occurred while loading the content.

Kate Oneal on Productivity

Expand Messages
  • Ron Jeffries
    From /The Annals of Kate Oneal/ =============================== Early in her tenure as CTO, Kate Oneal had sent down a brief note to her teams, saying I d like
    Message 1 of 192 , Feb 26, 2008
    • 0 Attachment
      From /The Annals of Kate Oneal/

      Early in her tenure as CTO, Kate Oneal had sent down a brief note to
      her teams, saying

      I'd like the teams to work on improving productivity. Each team,
      please put together a team plan for how to do that, and how to
      communicate it briefly, in writing, so that I can roll up your
      reports and package them for the executive team. I'd like your
      plans by the first of the month, please.


      Kate's teams had various reactions, ranging from hunkering down to
      starting to track some metrics to see what they could find. The
      Rimshot team had talked among themselves. There were a few main
      schools of thought:

      Susan said, "Kate should tell us what she means by productivity and
      how to measure it, so that we can do exactly whatever she wants."

      Bill said, "We should resist this with all our might. Everyone knows
      that optimizing numeric measures doesn't work."

      James said, "We should figure out some ways to improve and show that
      we have, and give her that information."

      David said, "Maybe we should wait and see what other teams do."

      Bill said, "No! This is just another damn scheme to get more work
      out of us."

      James said, "It's not that bad. We don't know Kate well enough yet,
      and she doesn't know us. We should work on building a trust

      Bill said, "I'm a programmer, Jim, not a shrink. I do code, not

      Everyone laughed at the old schtick.

      The discussion seemed likely never to end, so they decided to set
      up a meeting with Kate to talk about the request.


      A few minutes before the meeting, everyone was in Kate's meeting
      room, ready to go, as people always were for her meetings. Just as
      the clock ticked the hour, they heard the sound of Kate's wheels in
      the hall, and she whipped into the room and pulled to a stop at her
      accustomed spot at the table.

      Bill, who had been sure Kate would be late at last, whispered to
      Alan next to him: "How does she do that? One minute she's nowhere
      to be found, the next she's here."

      Across the room, Kate said, "Teleporter in the wheelchair. I was in
      Denver a moment ago."

      Everyone laughed. But how had she heard that?

      Kate opened the meeting: "Hi, guys, what's up?"

      If the team had been standing, they would have shuffled around
      until James was somehow at the front of the group. As the suddenly
      designated spokesman, James decided to speak.

      "Well, you sent out that memo about productivity?"

      "Yes," said Kate.

      "Well, we wanted to talk about it."

      Kate smiled and waited.

      "We want to find out what you want, so that we can do it," James

      "So you want to find out what's needed, so you can do it?" Kate

      "Yes. What's needed."

      "OK, ask away."

      "Well," said James, "what do you need?"

      "What I'm asking for is that we improve productivity, and do it in
      a way that shows how we're doing."

      "OK, well, what is improved productivity?" James asked.

      "What do you guys on the Rimshot team do?" asked Kate.

      Down at the corner, Bill leaned over to Susan and whispered.
      "Doesn't she even know what we do?"

      Susan whispered back, "She knows everything."

      Kate looked briefly at Susan, smiled, and nodded. But how had she
      heard that?

      Kate, "So, pretend I don't know. What does your team do?"

      "Well, we do stories for the Rimshot product owner."

      "Good," said Kate, "I hoped that was it. What might productivity
      mean to you then?"

      Silence. Then Susan said, "We could do more stories?"

      Kate replied, "That sounds good. Would more stories mean more
      productivity, then?"

      Bill had to correct this mistake. "Not necessarily, what if we did
      more stories but they had more bugs in them."

      "Bugs are bad, right?" asked Kate.

      "Duh. Of course they are," said Bill.

      Kate grinned. "Duh, indeed. So would fewer bugs be better?"

      "Sure," said Bill.

      "Wait," said Susan. "What if we had fewer bugs but also fewer
      stories? That might not be good."

      "I see," said Kate. "How do the number of stories and the number of
      bugs come into productivity then?"

      The team conferred briefly. James got pushed forward again. "Well,
      more stories is basically better, unless something else gets worse.
      And fewer defects is basically better, unless it slows us down too

      "Sounds right to me," said Kate.

      "So you're saying we should record defects and number of stories and
      work to get the one up and the other down?" asked Bill.

      The team knew this was a trick question. So did Kate. "It's your
      decision. But if you just worked to those numbers, wouldn't there be
      a way to game them? Not that you would do that on purpose of

      Kate had trumped Bill's ace. "Yes. Our biggest concern with metrics
      is that they will just drive us to do bad things. Even if we track a
      lot of metrics, it just gets more and more complex and still doesn't
      drive real results."

      Kate said, "That's right. One of my favorite books relating to that
      is 'Punished by Rewards', by Alfie Kohn. What I get out of that
      book is that incentives, rewards, and punishements don't really
      work very well. I have a copy in my office if anyone wants to
      borrow it.

      "But still," Kate went on, we aren't perfect, are we? We do have
      room for improvement? Is there some way to improve, and to know it?"

      The team thought a bit, then James stepped in. "Well, there are
      things we do that waste time. When we were getting ready for this
      meeting, someone pointed out that we spend too much time fixing
      integration problems. It's something like eight person hours a
      week. That's a whole day!"

      "If you reduced that time, what would it give us?" asked Kate.

      "Well, more time," James said.

      "Why would that be good?" said Kate.

      "Um. We could spend that time doing something more productive. It
      would give us a whole day to refactor, for example."

      "Why should I like refactoring?", Kate asked.

      "It makes the code cleaner," Bill said.

      "And why should I like cleaner code?"

      "We go faster when the code is clean."

      "And faster is good because?", Kate said.

      "Well, because we'll get more stories done?" Bill said.

      "That would be good, if it didn't get in the way of other good
      things, wouldn't it?" Kate said.

      "Yes," said James. "If we cut back on those integration things, we
      would be less stressed, we could do a bit better job on keeping the
      code clean, and we might be able to slip in another story as well.

      "Would it be OK if we gave you a plan that, over the next few
      months, said we wanted to reduce integration problems, turning
      those hours into productive time?"

      "Sounds good," said Kate. "Is there some way you could show where
      that time went? I suspect people would like to know it was used

      "Here's an idea," said Susan. "What if we set our goal to be to
      reduce the time wasted fixing integration problems, and to move
      that time to more valuable activities. We could report progress
      with two little graphs, one showing something like number of
      integration problems and time to resolve, and the other graph
      showing our percentage allocation of time overall."

      "What would that second graph show us?" said Kate.

      "It would show how we're spending time. If we do things that make
      us better, we will probably see more time going into good things
      like new stories and refactoring, and away from bad things like
      fixing bugs and hassling with integration," Bill said.

      "It sounds good to me. Can you think about that and decide if you
      want to go that way, and if not, use that idea to come up with
      something better?" said Kate.

      The team conferred. "Yes, we can do that," said James. "And we
      will. Thanks."

      "Thank you, people. I look forward to seeing what you come up with."

      The Rimshot team walked back to their open space. Everyone was
      pretty happy.

      "OK," said Bill, "we got her to answer our questions and we don't
      even have to do any stupid metrics."

      Everyone began to agree, then Alan said, "Wait. Kate didn't answer
      our questions at all. We figured it out, right in front of her."

      Far away, in her office, Kate smiled and nodded.

      Ron Jeffries
      Debugging is twice as hard as writing the code in the first place.
      Therefore, if you write the code as cleverly as possible, you are,
      by definition, not smart enough to debug it. -- Brian Kernighan
    • Ron Jeffries
      ... I freely grant that having someone come in and point to issues in the code is helpful. But I ve never seen a team where none of them knew they were
      Message 192 of 192 , Mar 10, 2008
      • 0 Attachment
        Hello, Steven. On Friday, March 7, 2008, at 8:23:05 PM, you wrote:

        >> Why do you say this? Every team I've ever had anything to do with
        >> knew when it was producing crap.

        > Ron,

        > Before you had associated with them, or only after you had
        > enlightened them?

        I freely grant that having someone come in and point to issues in
        the code is helpful. But I've never seen a team where none of them
        knew they were producing junk. Of course, I only see teams who are
        at least somewhat aware that they need help.

        > I have encountered quite a few teams this century who were quite
        > openly proud of their cleverly engineered proprietary DAO, not
        > understanding that they had in reality wasted several person-months
        > creating something inferior to freely available frameworks like
        > Hibernate and whose maintenance was going to degrade their velocity
        > until they finally gave up their pride and replaced it with
        > (N)Hibernate (or the equivalent).

        > Seriously, you have not encountered this phenomenon?

        You describe a phenomenon illustrating my point, where a team
        realizes that their home-grown DAO is holding them back. Yes. It's
        an example of teams figuring out that they are producing / have
        produced crap.

        And my guess is that some of them knew long before, and quite
        possibly even said so. If a team is any good at all, at least some
        of them know.

        Ron Jeffries
        If you don't have the courage to say what you think,
        there isn't much use in thinking it, is there?
        --Thomas Jay Peckish II
      Your message has been successfully submitted and would be delivered to recipients shortly.