Repair a Leaky Cuisinart

My Cuisinart Grind and Brew developed a leak. There was a small hole in the plumbing. It would leak all over the counter. That made it more of a Cussinart in my household. Here's how I fixed it with a little metal epoxy that I got from the local hardware store.

Most of the posts I see online about leaky Cuisinarts blame a clogged thermos lid, using too much coffee, using too finely ground coffee, or a clogged filter. If yours is leaking clear water like mine did, the problem isn't any of those. Before I opened it up I suspected a leaky hose or a cracked reservoir (though there really shouldn't be any reason for the reservoir to crack).

There are 4 hex or torx-bit screws holding the bottom panel on. My tools weren't skinny or long enough to fit in the narrow hole, so I just drilled the holes out. I probably used a 7/16" bit.

When I opened it up I saw a rusty (and cheap) clamp on those big orange hoses. I thought that might be the problem. But I also saw some discoloration in a spot on the aluminum pipe. Now that I had the bottom off I filled it up with water to find the source of the leak. I saw that it was leaking from the aluminum. So, I sanded the area of the leak and cleaned it off. That made the hole more visible. I patched it with some epoxy made for metals that I got from the local hardware store. The smallest size cost $6 and is much much more than I'll ever need, but that's cheaper than a new Cussi..., er, Cuisinart.

Since I drilled out the bottom I can't just reattach it with the original screws. I'll use a little glue (not too much) to hold the bottom on. Superglue might work. JB Weld would work well. Some other assorted craft glues that I have lying around should work.

If yours has a leaky hose, that should likewise be an easy fix. You can get a new hose from your hardware store. Zip-ties and new clamps are easy to come by.

Good luck! Let me know if you find this useful.

My Recent Posts on LeadingAgile

I started working with LeadingAgile in 11/2012 on some complex enterprise agile transformations and other lean management consulting. Related to that, I've done most of my recent blogging over there on LeadingAgile's blog. Here are some of those posts:

I Don’t Estimate Software Defects, but it's not as simple as just that. If you follow my advice, you'll also have a zero-defect mentality and you'll fix defects as soon as you find them. In general, I want a conservative measure of velocity, so I don't record in my velocity anything that was unplanned. Therefore, I likewise Don't Estimate Spikes.

I'm fond of The Theory of Constraints and Brooks’ Law. In that post I evaluated Brooks' Law in light of the Theory of Constraints in a way that I hope helps the reader understand both concepts.

Lack of Predictability is Your Biggest Problem. The senior leadership in most organizations I work with seem to agree. They aren't very interested in agile's agility. They want their design-build-test teams and their program teams to be able to make and meet commitments so they can make appropriate capacity constrained commitments across the portfolio and to external stakeholders.

Agile Health Metrics for Predictability was perhaps my most popular post on LeadingAgile's blog.

In Bottom-Up Implementation & Top-Down Intent, I discuss my recommended approach to agile transformations.

Related to that, I wrote a post arguing that you should fix your Structure 1st: Why You Should Not Start With Practices

Part of your structure involves your design-build-test teams, also known as your Scrum teams. In Use Feature Teams. Yes, Use Component Teams I explaining these approaches and why I recommend using both.

What do Scrum teams do during the Release Sprint? Good question. This post has the answer. In short, many things, but not developing code that can't be tested immediately.

Oh, I also published an article in Agile Journal entitled Identifying and Improving Bad User Stories along with my friend and co-author Chuck Suscheck. We put another article up on sticky-minds: The Problems with Overachievers on Agile Teams.

What's DOING in Personal Kanban?

What do you do with Stories on your Personal Kanban that you are going to put aside for a day or three?

I'm committed to limiting my Work In Process (WIP) and to "stop starting / start finishing" but some stories/tasks just need to be put aside. I'm not talking about tasks that are blocked, waiting on someone else. Those I'll either flag or move to a Waiting/Blocked column. Rather, this post is about stuff that I need to stew on or need to come back to when my mind is ready. What do you do with those? Herein I'll tell you what I do, but I'm really interested in what you do. Please post your thoughts and ideas in the comments.

I don't have a HOLD column on my personal kanban wall. Hold seems to be a misnomer for me. It's a kind of lie. The work really still is in progress. It's WIP. I'm going to come back to it this week, maybe tomorrow, maybe even today. It ain't done.

I could split my task or story each time I feel the need to set one aside, putting part of it in DONE and part of it back in a ready column, but I kind of like my definition of what is a story, what is a task and what is a next-action (or sub-task). I don't want to monkey with that. Anyway, splitting stories is a kanban hazard.

PROJECTS, STORIES, TASKS, NEXT-ACTIONS & SUB-TASKS

For the following discussion you need to understand my context:

I have Projects (held in a folder) that get broken down into multiple Stories, each Story on its own stickie. Some Stories are stand-alone, not related to any Project.

I also have some Stories that have multiple "next-actions" (or tasks or sub-tasks, whatever you choose to call them). In the spirit of Getting Things Done (GTD), I note the next-action, or next several actions, on the Story stickie. Often, each one of these next-actions might take 5 minutes or less, so they don't seem to be a Story deserving of a stickie of their own.

So here's what I do for those tasks in that nebulous state of not done but not active either. I'd love for you to add your thoughts in the comments.

IT'S DOING

Some of my to-dos need time to stew, such as writing a blog post. I have lots of outlines and rough drafts. I create drafts quickly when the idea comes to me. Such activity never enters my personal kanban. In the spirit of GTD, if it takes less than a couple minutes to do, just do it. I very rarely create a Task or Story for such activity.

But when I select a draft blog post to finish, I put the blog-post Story on my personal kanban in DOING and leave it there until I'm done-done. But I won't finish it in one setting. I'll flesh it out and let it sit. I'll come back to it, pretty it up, put in some links and gather some photos, and let it sit. I'll proof read and polish it and paste it into blogger, and let it sit. I'll come back to it some morning to be sure it's ready to go, publish it, and tweet it. During all of that, I might add a next-action (sub-task) either into my draft blog post (such as "--insert photo here--") or onto the stickie (such as "trim the photos").

I'm pretty satisfied with how I do that.

IT'S DONE FOR TODAY AND A TODO FOR TOMORROW

Other times I'll have a to-do that I want to work on a little each day, such as practicing a coding kata or revising/rehearsing a short speech. Maybe I'll put a "next action" (sub-task) for each day of the week on the stickie and check them off as I go.

I don't usually leave those in DOING for the week. If I've done it for today, I don't like leaving it in the DOING column. I usually move them back to some ready column each day. But it's still in progress for the week.

I'm not completely satisfied with how I do that. Sometimes I've left such a story in DOING.

What do you think about this? Do me a favor and post your thoughts in the comments before you go.