Kate Oneal: Handling Defects

This content is syndicated from xProgramming.com by Ron Jeffries. To view the original post in full, click here.

A few minutes before 9, the team was in the coffee room.

“What time’s the meeting?” said Gil. “Is she here?”

“Nine sharp,” said Susan. “I just went by her office. She’s not there.”

“Carl and I have been working in here since 8,” Gil said. “She hasn’t been here for a Diet Coke.”

“This is the day,” Carl said. “She’s late. Let’s go!”

When the team came into her office, Kate was by her window. She spun her wheelchair and scooted to her usual spot at the table.

“How do you do that?” said Gil.

“It’s easy. To spin, push one wheel, pull the other. To go forward, push both. To turn, grab one. To stop, grab both.”

“No, how do you always get to meetings right on time?”

Kate smiled. “That’s easy too: you leave wherever you are as many minutes as it’s going to take to get wherever you’re going.”

Carl said, “You have a Diet Coke.”

“Yes. Yes, I have.”

“It must be warm.”

Kate felt the can. “No, it’s nice and cold. The machine is working just fine.”

“I mean, how did you get it? Did you bring it to work with you?”

“Standard way. Put coins in slot, press the button. I suppose I could have thrown the coins across the room into the slot and tossed my exercise ball against the button, but I’d still have to go get the can.”

“No one could do that,” said Gil.

Kate smiled. “Maybe no one ever tried. What’s this meeting about?”

On his way to the coffee pot, Carl said, “We want to talk about what to do about bugs.”

“Great,” Kate said. “Let’s not have any.” She clapped her hands. “Meeting over?”

Susan laughed. “As Product Owner, I’m good with that. Move to adjourn.”

“Not so fast,” said Gil. “There are always going to be bugs. We have to handle them.”

“I knew it couldn’t be that easy,” said Kate. “What about these defects?”

Gil said, “Well, should we put them into a database? How should we decide which ones to fix?”

Kate said, “Who decides what features you work on?”

Gil said, “Susan, as you well know.”

Kate laughed. “Yes, as we all well know. So … who should decide which broken features to fix?”

Gil said, “Susan?”

“Good idea. Susan.”

Carl, having returned to the table, interrupted. “Oops. I forgot sugar. Sugar, please.”

Kate dipped two fingers into the bowl of sugar packets, and pulled one out. “Don’t move,” she said, and flicked the packet at Carl. It hit him in the chest and dropped into his shirt pocket.

“How did you do that?”

“Easy. Your nerd pack pulls your pocket open.”

Everyone laughed.

Carl frowned. “You never know when you might need a pen. Or a marker. Or a drawing pencil. Or another pen …”

“True that,” Kate said. “So what else about these defects?”

Susan said, “Well, we need to decide just how to handle the scheduling, how to count velocity, and things like that. And if there are a lot of them, how should we keep track of them?”

Kate said, “How do you schedule things now?”

Susan grinned. “Why do you ask questions you know the answers to? I write a short description on a card. If I need help deciding what to write, or need to be sure the idea makes sense, I talk about it with the team. Also, I meet with the testers to work out the correctness checks. We do that about once a week. Then at the planning meeting, I bring enough cards and checks to fill the week, we talk through each one, figure out how many the team can take on, and commit to the work.”

Kate paused, then said,”Why do I ask questions I know the answers to?”

Susan stared. Then, “Oh. If I want a bug fixed, I could write it on a card and bring it to the meeting?”

“Sure could,” said Kate. “But you mentioned something else that you bring.”

“The checks,” said Susan. “The testers and I could bring in some checks for the bug. They always figure out a way to reproduce it anyway.”

Kate smiled. “Sounds good to me. But isn’t there something special about these defect checks?”

Everyone looked confused. Finally, Charlie, a tester, spoke up. “Oh. We should have provided those checks the first time. We screwed up by not having them.”

Kate said, “I’m not into blame, and anyway we can’t go back on our own time line and edit the past. But we do have a good learning opportunity. What can we do to take advantage of that?”

Carl said, “The retrospective. We should look at the defects discovered and see how to do a better job of creating checks for them.”

“Good idea, Carl, and well put,” said Kate. “I noticed that you said ‘we’. Why did you put it that way?”

“Well, we programmers are in those story meetings too, and we help with the examples. Often a bug …”

Kate said, “Defect.”

“… yes, defect. Often a defect comes out in some odd coding case that a programmer might foresee and a tester might not. Anyway, we’re all in this together, so let’s all learn.”

Gil said, “There’s another chance to learn, sooner. That’s as soon as the bug — defect — is found. The testers usually grab a programmer right away, to be sure they understand the situation, and maybe to figure out how to reproduce it.

“Often, we see right away what is going on. That’s the moment to start learning.”

“Yes! Good point, Gil.” Kate looked delighted. “Now you said something about velocity?”

Susan said, “Yes. How should we handle velocity for bu … defect cards.”

Kate said, “Here’s a question I know the answer to: how do you use velocity?”

Susan said, “I use it in my product burn chart, to get a sense of how much we’ll have by the final ship date.”

Carl said, “And we use velocity to estimate how much work we can take on in the Sprint.”

“OK,” said Kate. “Two reasons: know how many features we’ll have by the ship date, and know how much work to take on in the Sprint. Do defects take time to fix? Can we estimate that time for the Sprint?”

Carl grinned. “They do, unfortunately, and we can usually estimate them pretty well. Sometimes we need to take some time to dig in a bit before we know.”

“If you don’t know how long a fix will take, what do you do?”

Carl went on. “Often we just guess how much time it’ll take or how many we can do. That works pretty well. If it’s a really weird one, we usually ask Susan to authorize a time-boxed exploration.”

“A spike,” Kate said.

“Yes. Then we usually know how long the thing will take. In fact, quite often we actually find and fix it inside the spike timebox.”

“OK,” Kate said, “it sounds like you’re totally on top of estimating defects into the Sprint. What about planning toward the release, Susan?”

Susan frowned a bit. “Defects are really a hassle. Usually they’re important, and I have no choice but to fix them. But they don’t fit into my planning at all.”

“Why not?”

“Well, even if I knew how long they take — and I think they probably average out well enough — I don’t know how many there are going to be.”

Kate said, “Couldn’t we just take that average as well? Like if you’re fixing five defects a Sprint, we just assume that if we have ten Sprints left, we’ll have fifty defects to fix?”

Susan said, “Well … we could …”

“So then,” Kate went on, “we could factor the defect fix time right into the planning and tracking. We could bump up the burn chart by fifty, and track the defects just like stories.”

Susan said, “We could, but that makes me feel kind of dirty. Defects are bad. Yes we can learn from them. For example, I learn how to say more clearly how things have to work, and I work closer with Charlie and the rest of the team coming up with examples that help us be sure things work. And I know the programmers are learning how to do their tests better, and better ways of designing things. But …”

“But what?” said Kate.

“I don’t want defects! When I have to schedule a defect fix, even when I can see it’s because of a test that I should have seen, I just don’t get the same thrill I do when I see the gang finish one of my features.”

Gil said, “You just want to punish us, or yourself, for making mistakes. Bugs are inevitable. They just happen.”

Kate said, “Hold on a second. Maybe some defects are inevitable. But aren’t you all learning ways to avoid them and make them less likely?”

Gil said, “Well, yes. Carl and I learned a new way of testing without going to the database last week, based on something Carl read about. That makes it a lot easier to write tests, and much faster to run them. I can identify a bug that I’m sure we would have had two weeks ago, avoided now because we can test better. But still, bugs will happen.”

Kate said, “They will. One reason I like to say ‘defect’, though, is to remind myself that whenever I look back at a ‘bug’ in the system, I can almost always find something concrete that I, or someone on the team, or all of us together, could have done to prevent it. Saying defect reminds me that most of them are up to us to avoid or prevent.”

Gil said, “There will always …”

Kate said, “Yes. There will always be defects. But do this for me. The next time one shows up that was absolutely unpreventable, bring it to a meeting with me. I’ll bet that by the time the meeting is over, we’ll know a way we could have prevented it … and a way that isn’t even all that costly. Meanwhile, let’s pretend that they are all preventable: most of them clearly are.”

Susan said, “So what does this say about planning?”

“Way to keep us on track, Susan. You’re right to feel bad about defects. There are two kinds of demand for work, according to the Lean and Systems Thinking people. Who knows what they are?”

Silence. Then, Susan said, “I don’t know the words, but there are the things our customers actually want and the things I have to do because the software isn’t right.”

Kate clapped. “Exactly right. The words they use are ‘value demand’ and ‘failure demand’. Value demand is the demand for what customers actually want. Failure demand is work we have to do because we are imperfect … because we have room for improvement.

“So I think you’re on the right track, Susan. I would suggest that you should not bump up your target by some expected number of defects, and you should not count defect fixes as features on the burn chart. If you do that, and there are defects, what will happen?”

Susan thought a moment. “My progress line won’t grow so fast. Each defect we fix takes away that much work on a feature. The chart will show us slowing down to the extent that we work on defects.”

“Right!”, said Kate. “Defects do slow us down, and in an unpredictable way. So it makes sense to me not to track them on your chart as if fixing them were a good thing. It’s more of a necessary evil.”

“But wait!” Carl, this time. “Those bugs can be hard to fix. We put in real work on those. We should get credit for that work.”

Kate grinned. “Remember the story lady? She comes in every Friday, looks on your shelves for features, and buys what you have, putting dollars in your pockets and lattes on your desks? What’s that beautiful redhead going to say when she finds a defect fix on the shelf? Am I going to pay for it?”

Carl smiled back. “I guess not. You’re going to say that you already paid for that feature and you want the fix for free.”

Kate said, “That’s right. Making me pay for defects ain’t workin’. I won’t pay money for nothin’. I want my fix for free.”

Everyone groaned.

“Welcome to my earworm. So, do we have a plan? Estimate for the Sprint as usual, don’t put defects on the Product Burn Chart, either in the target or in the progress?”

Everyone agreed.

“Great,” Kate said. “Meeting adjourned. Thanks for stopping by.”

As they started to leave, Carl turned. “One more question, Kate?”


“Could you really throw your exercise ball and hit the Diet Coke button?”

“Is there money riding on it? Come over to the Bombay some evening and play a game of darts with me. Then we can talk about the exercise ball … and the coin slot.”

Leave a Reply

Your email address will not be published. Required fields are marked *

19 + 3 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”



To explore how we can help you, please get in touch